Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

[Thijs Kinkhorst]

Hi Jakub,

On Wed, March 9, 2016 11:50, Jakub Wilk wrote:
> * Arno Töll , 2015-08-21, 11:13:
>>The fix would be, to raise this Lintian error only if a package depends
>>on apache2-bin but not on apache2-api-MMNN.
>
> There's already separate tag for missing apache2-api-* dep:
> apache2-module-does-not-depend-on-apache2-api
>
> Should we should drop apache2-module-depends-on-real-apache2-package
> completely?

Yes. Some of my packages have been triggering this Lintian error for a
long long time now, while all they do is depend on dh-apache2 and let that
sort out the correct misc:depends.

Please remove the test.


Cheers,
Thijs

Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

[Thijs Kinkhorst]

Hi,

On Fri, 21 Aug 2015 10:19:06 -0700, Russ Allbery wrote:
> > we agreed that we should change Lintian to accommodate these
> > changes. The fix would be, to raise this Lintian error only if a package
> > depends on apache2-bin but not on apache2-api-MMNN.
>
> Ah, yes, that would work.

So, any update on this issue? The test is still triggered on my package as
at level error with "Severity: serious, Certainty: certain".


Cheers,
Thijs

Bug#775667: lintian: Create a command line to suppress excess tags

[Thijs Kinkhorst]

On Mon, August 31, 2015 07:46, Niels Thykier wrote:
> On 2015-08-30 20:28, Axel Beckert wrote:
>> Hi,
>>
>> Niels Thykier wrote:
 Moreover minified js is a security risk so removing tag is not really
 an option
>>>
>>> The bug is not about removing the tag, it is about the amount of times
>>> it is emitted makes it difficult to spot other issues.
>>
>> Yep, wanted to argue, too. But Niels was quicker
>>
>>> This is not the only tag with this issue (improper stripping of static
>>> libraries also do this), and I think we need to look into a solution
>>> for
>>> this at a general level.
>>
>> What about a command-line and/or configuration file option which
>> restricts the amount of tags of the same type to be printed at all?
>>
>> Example option: --max-output-same-tag=10
>>
>>  Regards, Axel
>>
>
> Yes.  Though I would prefer lintian did something like this by default
> when stdout is a tty.  Also, 10 instances of a single tag is quite a
> lot, I think 1-3 and a "+X more instances of this tag"-remark would be
> sufficient for most users.

That would be a nice feature and I think it makes sense as the default.

Nonetheless, the original issue could also be addressed by modifying the
test not to issue a tag on each of the potentially over 100 files it
encounters, but rather do something like:

if (any of the tinymce files found) {
  issue tag ("tinymce found")
}


Cheers,
Thijs

Bug#775667: source-is-missing generates excessive amount of tags

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.30
Severity: normal

Hi,

The 'source-is-missing' check can generate really excessive output of many
hundreds of tags when just a single source is missing. Take for example
roundcube which currently has 800+ tags which nearly all relate to tinymce
missing:
https://lintian.debian.org/maintainer/pkg-roundcube-maintain...@lists.alioth.debian.org.html#roundcube

This huge amount of output makes Lintian hard to use and effectively drowns
out any other warning or error.

Cheers,
Thijs


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150118113208.876.70759.report...@tetraquark.soleus.nu

Bug#718862: composer-package-without-pkg-php-tools-builddep should not be a warning

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.15
Severity: normal

Hi,

Lintian 2.5.15 added a number of tests related to pkg-php-tools.
The test composer-package-without-pkg-php-tools-builddep displays
a warning on every package containing a composer.json file.

This seems over the top to me. My PHP application has functional
packaging developed over the years and I see no urgent need to
throw it away and rebuild it in pkh-php-tools just because upstream
also ships a composer.json.

I would recommend to flag this as info at best. In general,
I would also advise to add new tests as experimental initially.


Cheers,
Thijs


-- 
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/20130806100200.10399.92867.report...@flowsel.uvt.nl

Bug#718167: missing-pkg-php-tools-addon thinks I'm using pkg-php-tools

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.15
Severity: normal

My package phpmyadmin triggers the following warning:

  W: phpmyadmin source: missing-pkg-php-tools-addon phpcomposer
  N: 
  N:The package uses pkg-php-tools but dh command is called without --with
  N:phppear or --with phpcomposer. A PECL package should also have --with
  N:php5.

However, my package is not in fact using pkg-php-tools. There seems to be
a conditional missing in the test.


Cheers,
Thijs

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

Kernel: Linux 3.10-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.23.52.20130727-1
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   1:5.14-2
ii  gettext0.18.3-1
ii  hardening-includes 2.3
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.34-1
ii  libdpkg-perl   1.17.0
ii  libemail-valid-perl0.190-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.5-2
ii  patchutils 0.3.2-2
ii  perl [libdigest-sha-perl]  5.14.2-21
ii  t1utils1.37-2

Versions of packages lintian recommends:
pn  libperlio-gzip-perl none
ii  perl-modules [libautodie-perl]  5.14.2-21

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.17.0
ii  libhtml-parser-perl3.71-1
pn  libtext-template-perl  none
ii  xz-utils   5.1.1alpha+20120614-2

-- 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/20130728093613.29149.56108.report...@flowsel.uvt.nl

Bug#711520: non-standard-apache2-module-package-name suggests strange name for libapache2-mod-php5

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.10.4
Severity: normal

Hi,

On libapache2-mod-php5_5.5.0~rc2+dfsg-2_amd64.deb I get:
W: libapache2-mod-php5: non-standard-apache2-module-package-name 
libapache2-mod-php5 != libapache2-libphp5
E: libapache2-mod-php5: apache2-module-does-not-ship-load-file libphp5

However, the suggested 'libapache2-libphp5' is not in the expected module
naming scheme at all.

Perhaps this happens because the shipped module is
./usr/lib/apache2/modules/libphp5.so and Lintian wrongly uses this to
construct an expected package name.

The second test seems to suffer from the same problem: we do ship the module
file, the test makes a wrong assumption about its name.


Cheers,
Thijs

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils   2.22-8
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.2
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.13-38
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdigest-sha-perl 5.71-2
ii  libdpkg-perl   1.16.10
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.92-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.13-38
ii  locales-all [locales]  2.13-38
ii  man-db 2.6.2-1
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-21

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.10
ii  libhtml-parser-perl3.69-2
pn  libperlio-gzip-perlnone
ii  libtext-template-perl  1.45-2
ii  lzma   9.22-2
ii  man-db 2.6.2-1
ii  xz-utils [lzma]5.1.1alpha+20120614-2

-- 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/20130607124922.16982.13400.report...@incagijs.uvt.nl

Bug#711193: Mark hardening-wrapper/includes as deprecated build-depends

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.10.4
Severity: wishlist
Tags: patch

Hi,

Packages should not Build-Depend on either of these packages and their
functionality, but rather use the superior dpkg buildflags solution.
Attached patch accomplishes that packagers are warned when they
build-depend on one of these packages.


Cheers,
Thijs
From b7325c04d609f7bde87929c944475a6a3d5f3faa Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@debian.org
Date: Wed, 5 Jun 2013 12:25:14 +0200
Subject: [PATCH] Hardening-wrapper and hardening-includes are deprecated.

Packages should not Build-Depend on either of these packages and their
functionality, but rather use the superior dpkg buildflags solution.
---
 data/fields/obsolete-packages |4 
 1 file changed, 4 insertions(+)

diff --git a/data/fields/obsolete-packages b/data/fields/obsolete-packages
index 5d0b20a..2449a69 100644
--- a/data/fields/obsolete-packages
+++ b/data/fields/obsolete-packages
@@ -68,3 +68,7 @@ libdigest-sha1-perl
 
 # Deprecated in Wheezy by maintainer (#646420)
 dpatch
+
+# Deprecated in Jessie, use dpkg buildflags instead
+hardening-wrapper
+hardening-includes
-- 
1.7.10.4

Bug#711193: Mark hardening-wrapper/includes as deprecated build-depends

[Thijs Kinkhorst]

On Wed, June 5, 2013 18:26, Russ Allbery wrote:
 Thijs Kinkhorst th...@debian.org writes:

 Packages should not Build-Depend on either of these packages and their
 functionality, but rather use the superior dpkg buildflags solution.
 Attached patch accomplishes that packagers are warned when they
 build-depend on one of these packages.

 Well, given that I have a package that Build-Depends on hardening-wrapper,
 I should probably reply here.  :)

 dpkg-buildflags is all fine and good if the upstream source lets you
 override compiler flags easily.  If, however, it doesn't,
 hardening-wrapper is much easier to deal with than trying to patch all the
 places in the upstream source where the compiler flags have to be changed
 and then updating that patch for various versions of upstream source.  In
 the case of openafs, this is a known bug that upstream is working on
 (slowly) by untangling the flags used to build the kernel module (which on
 platforms other than Linux cannot be user-tunable) and the flags used to
 build userspace, so doing the work to hack in Debian's flags in the
 meantime seems like a lot of wasted effort.

 What problem are you hoping to solve with this Lintian tag?

Hardening-wrapper/includes have existed as the solution for build
hardening before dpkg buildflags was introduced. Therefore, quite a lot of
packages adopted hardening-wrapper/includes and put them into their
Build-Depends. Now that dpkg buildflags is the agreed-upon superior
solution, it is better if they move to this solution if possible. The tag
would alert them of this fact, as would it signal new packages adding this
method (e.g. by copying it from another package).

There are still valid use cases, but as you say even there it's probably a
(known) bug in the build system that precludes the use of dpkg buildflags.
The packages themselves aren't going anywhere, it's just that there's a
large quantity of use that's most likely inertia. The valid use cases
could perhaps add an override?


Cheers,
Thijs


-- 
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/6a6ff8d3683b5da3fb1d64ad0151a9ba.squir...@aphrodite.kinkhorst.nl

Bug#700953: warn about binary packages depending on debhelper, cdbs etc.

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.10.3
Severity: wishlist

Hi,

I encountered an (example) package that had cdbs not only in its Build-Depends
line, but also in its Depends line. This was a mistake. I would have expected
that Lintian complained about this.

Obviously hardly any package would need to Depend on cdbs, or debhelper,
directly, with the notable exception of dh-* style packages and the occasional
other packaging helper here or there. I would suggest that cdbs or debhelper
being placed in a depends field is most probably an (easy to make) error and
could therefore be warned about, which the few packages that are actually
build helpers themselves could override.


Cheers,
Thijs


-- 
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/20130219161606.27772.84520.report...@incagijs.uvt.nl

Bug#698704: Add lua5.2 to list of known lua interpreters.

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.10.3
Severity: normal
Tags: patch

Hi,

lua5.2 is in the archive since 2011-07. Attached patch adds it to the list
of known lua interpreters.


Cheers,
Thijs
From b1879b43d57d1707a4ee3b6bace7998d0c72d841 Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@debian.org
Date: Tue, 22 Jan 2013 15:29:23 +0100
Subject: [PATCH] Add lua5.2 to list of known lua interpreters.

---
 data/scripts/versioned-interpreters |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/data/scripts/versioned-interpreters b/data/scripts/versioned-interpreters
index 304f9c6..350c018 100644
--- a/data/scripts/versioned-interpreters
+++ b/data/scripts/versioned-interpreters
@@ -71,7 +71,7 @@
 
 guile   = /usr/bin, guile-([\d.]+), guile-$1, 1.6 1.8,
 jruby   = /usr/bin, jruby([\d.]+), jruby$1, 1.0 1.1 1.2
-lua = /usr/bin, lua([\d.]+), lua$1, 40 50 5.1
+lua = /usr/bin, lua([\d.]+), lua$1, 40 50 5.1 5.2
 octave  = /usr/bin, octave([\d.]+), octave$1, 3.0 3.2
 php = /usr/bin, php(\d+), php$1-cli, 5, @NO_DEFAULT_DEPS@
 pike= /usr/bin, pike([\d.]+), pike$1 | pike$1-core, 7.6 7.8, @NO_DEFAULT_DEPS@
-- 
1.7.10.4

Bug#661778: update Ref for copyright-format checks to current location

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.5
Severity: minor
Tags: patch

Hi,

Please see attached patch: current Lintian copyright-format check
descriptions refer the user to dep.debian.org for more information;
this should be changed to the www.debian.org URL.

BTW, it may make sense to remove the 'dep5' from the check names,
since it's no longer a dep, but that has wider implications
so I'll leave that up to you.


Cheers,
Thijs
From 1cf0fe084aa0ec24f9ae6f8a83581f93b8440889 Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@debian.org
Date: Thu, 1 Mar 2012 09:27:47 +0100
Subject: [PATCH] update Ref for copyright-format checks to current location

The copyright-format specification now has a permanent location
at www.debian.org; update the references in the Lintian tag
descriptions accordingly.
---
 checks/source-copyright.desc |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/checks/source-copyright.desc b/checks/source-copyright.desc
index ba94a89..f707dd0 100644
--- a/checks/source-copyright.desc
+++ b/checks/source-copyright.desc
@@ -42,7 +42,7 @@ Info: Format URI of the machine-readable copyright file contains
 Tag: wiki-copyright-format-uri
 Severity: pedantic
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: Format URI of the machine-readable copyright file refers to Debian Wiki.
  .
  Debian Wiki is not used for the format development anymore.  Please use
@@ -52,7 +52,7 @@ Info: Format URI of the machine-readable copyright file refers to Debian Wiki.
 Tag: unversioned-copyright-format-uri
 Severity: pedantic
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: Format URI of the machine-readable copyright file is not versioned.
  .
  Please use
@@ -62,7 +62,7 @@ Info: Format URI of the machine-readable copyright file is not versioned.
 Tag: out-of-date-copyright-format-uri
 Severity: pedantic
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: A newer version of the machine-readable copyright file specification,
  than the one referenced by the copyright file, is available.
  .
@@ -71,14 +71,14 @@ Info: A newer version of the machine-readable copyright file specification,
 Tag: syntax-error-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The machine-readable copyright file didn't pass Debian control file
  syntax check.
 
 Tag: obsolete-field-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The machine-readable copyright file uses a field, that used to be defined
  by the specification, but has been renamed since then.
  .
@@ -91,7 +91,7 @@ Info: The machine-readable copyright file uses a field, that used to be defined
 Tag: comma-separated-files-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: A list of files in the machine-readable copyright format appears to be
  separated by commas.  The file list should be whitespace separated instead.
  .
@@ -100,28 +100,28 @@ Info: A list of files in the machine-readable copyright format appears to be
 Tag: missing-field-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The paragraph in the machine readable copyright file is missing a field
  that is required by the specification.
 
 Tag: missing-license-paragraph-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The files paragraph in the machine readable copyright file references a
  license, for which no standalone license paragraph exists.
 
 Tag: missing-license-text-in-dep5-copyright
 Severity: normal
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The standalone license header contains only short license name, but not
  the license text.
 
 Tag: unused-license-paragraph-in-dep5-copyright
 Severity: minor
 Certainty: possible
-Ref: http://dep.debian.net/deps/dep5/
+Ref: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Info: The license paragraph in the machine-readable copyright file is not
  referenced by any files paragraph.  It could be a typo in the license name or
  the license paragraph is simply not needed and can be removed.
@@ -129,6 +129,6 @@ Info: The license paragraph

Bug#661103: binaries-have-file-conflict not marked as experimental

[Thijs Kinkhorst]

Package: lintian
Version: 2.5.5
Severity: minor

Hi,

I got these new warnings when checking a package (false positives, btw):

W: gnupg source: binaries-have-file-conflict gnupg gnupg-curl
usr/lib/gnupg/gpgkeys_curl
W: gnupg source: binaries-have-file-conflict gnupg gnupg-curl
usr/lib/gnupg/gpgkeys_hkp

The tag description claims that these new tags are experimental, and they
are also not mentioned as 'added tags' in the changelog. I therefore think
they were mistakenly not classified as 'X' but was 'W'.


Cheers,
Thijs




--
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/e892ea106252853d8b2f465452cfc198.squir...@wm.kinkhorst.nl

Bug#615072: [checks/files] apply run-parts-cron-filename-contains-full-stop also to /etc/cron.d

[Thijs Kinkhorst]

Package: lintian
Version: 2.4.3
Severity: wishlist
Tags: patch

Hi,

Files under /etc/cron.d must conform to the same filename specs as those in
the cron.{hourly,daily,weekly} dirs, so it would be nice to check those for
dots aswell.

Attached patch accomplishes that.

One could perhaps consider to make the test inclusive rather than to check
just for the dot (check that files consist solely of upper- and lower-case
letters, digits, underscores, and hyphens), but as that would change the
original test I've not implemented that just now.


Cheers,
Thijs
--- checks/files.orig   2011-02-25 13:52:03.981454219 +0100
+++ checks/files2011-02-25 13:47:51.338568241 +0100
@@ -285,7 +285,7 @@
tag package-uses-obsolete-file, $file;
}
#  /etc/cron.daily, etc.
-   elsif ($file =~ m,^etc/cron\.(?:daily|hourly|monthly|weekly)/[^\.].*\., 
) {
+   elsif ($file =~ 
m,^etc/cron\.(?:daily|hourly|monthly|weekly|d)/[^\.].*\., ) {
tag run-parts-cron-filename-contains-full-stop, $file;
}
#  /etc/cron.d

Bug#574826: example-interpreter-not-absolute false positive for non-executable files

[Thijs Kinkhorst]

Package: lintian
Version: 2.3.3
Severity: minor

Hi,

My package triggered the following info-level Lintian tests:

I: eekboek: example-interpreter-not-absolute 
./usr/share/doc/eekboek/examples/Kasverkoop.pm #!perl
I: eekboek: example-wrong-path-for-interpreter 
./usr/share/doc/eekboek/examples/Kasverkoop.pm (#!perl != /usr/bin/perl)
I: eekboek: example-interpreter-not-absolute 
./usr/share/doc/eekboek/examples/Userdefs.pm #!perl
I: eekboek: example-wrong-path-for-interpreter 
./usr/share/doc/eekboek/examples/Userdefs.pm (#!perl != /usr/bin/perl)

I believe these tests to be false positives, as the files in question are not 
installed executable (and rightly so, since they're Perl modules, not Perl 
scripts). Since they are not executable, the value of the first line is 
irrelevant.


cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.

Bug#529924: duplicate-short-description between deb and udeb

[Thijs Kinkhorst]

Package: lintian
Version: 2.2.10
Severity: minor

Hi,

My package 'gnupg' generates the following info-level tag:

   duplicate-short-description gnupg gnupg-udeb

I believe this may be inappropriate where the description overlap is
between the deb and its associated udeb. In the Lintian report for this
tag I see a number of other packages that are tagged for this.

The packages in fact do the same, so that they share the description is
not a surprise. That one is a udeb is already flagged by other means like
the section and package-type fields.

cheers,
Thijs




--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#517899: internal error: command failed with error code 123 in collect info file-info

[Thijs Kinkhorst]

On tiisdei 3 Maart 2009, Russ Allbery wrote:
 Thijs Kinkhorst th...@debian.org writes:
  I get the following output when I check a mailman source package.
 
  $ lintian mailman_2.1.12-1.dsc
  Use of uninitialized value $_ in substitution (s///) at
  /usr/share/lintian/collection/file-info line 50, INDEX line 1.

 Could you try applying the following patch under /usr/share/lintian and
 see if it reliably fixes your problem?

In fact it does fix the problem for me; it doesn't occur anymore in 
reproducible situations where it used to. Lintian seems to function fine for 
several different packages. Thanks!


Thijs


signature.asc
Description: This is a digitally signed message part.

Bug#517899: internal error: command failed with error code 123 in collect info file-info

[Thijs Kinkhorst]

Package: lintian
Version: 2.2.6
Severity: normal

Hi,

I get the following output when I check a mailman source package.

$ lintian mailman_2.1.12-1.dsc
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 50, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 51, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 52, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 53, INDEX line 1.
Use of uninitialized value $_ in printf at 
/usr/share/lintian/collection/file-info line 54, INDEX line 1.
internal error: command failed with error code 123
warning: collect info file-info about package mailman: 512
warning: skipping check of source package mailman

Odd thing is that I cannot reproduce it when running lintian with
the -d switch, so I'm having a bit of trouble pinning it down.

The package in question can be found here (may not be of release quality):
http://people.debian.org/~thijs/mailman/

cheers,
Thijs

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-xen-686 (SMP w/1 CPU core)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils   2.19.1-1  The GNU assembler, linker and bina
ii  diffstat   1.46-1produces graph of changes introduc
ii  dpkg-dev   1.14.25   Debian package development tools
ii  file   4.26-2Determines file type using magic
ii  gettext0.17-6GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libipc-run-perl0.82-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.1600-9  Time and date functions for Perl
ii  liburi-perl1.37+dfsg-1   Manipulates and accesses URI strin
ii  man-db 2.5.4-1   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.0-19 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
ii  libtext-template-perl 1.44-1.2   Text::Template perl module
ii  man-db2.5.4-1on-line manual pager

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#517899: internal error: command failed with error code 123 in collect info file-info

[Thijs Kinkhorst]

On moandei 2 Maart 2009, Adam D. Barratt wrote:
 The error suggests that the index file which Lintian has generated of
 the orig tarball contains a line in an unexpected format as the first
 line - specifically, it does not contain at least six space-separated
 fields.

 Unfortunately I'm currently unable to reproduce the error using either
 Lintian 2.2.6 or current HEAD (on amd64/sid and in an i386/sid chroot).
 If it's consistently failing for you, could you please re-run the test
 passing --keep-lab and check what the first line of the file
 source/mailman/index contains? (Using -v as well will indicate the
 directory name used for the temporary lab).

The strange thing is that it's only reproducible when not passing
--keep-lab. It is however reproducible with -v:

$ lintian --keep-lab mailman_2.1.12-1.dsc
W: mailman source: debhelper-but-no-misc-depends mailman
$ lintian  mailman_2.1.12-1.dsc
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 50, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 51, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 52, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 53, INDEX line 1.
Use of uninitialized value $_ in printf at 
/usr/share/lintian/collection/file-info line 54, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 50, INDEX line 2.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 51, INDEX line 2.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 52, INDEX line 2.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 53, INDEX line 2.
Use of uninitialized value $_ in printf at 
/usr/share/lintian/collection/file-info line 54, INDEX line 2.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 50, INDEX line 3.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 51, INDEX line 3.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 52, INDEX line 3.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 53, INDEX line 3.
Use of uninitialized value $_ in printf at 
/usr/share/lintian/collection/file-info line 54, INDEX line 3.
internal error: command failed with error code 123
warning: collect info file-info about package mailman: 512
warning: skipping check of source package mailman
$ lintian -v  mailman_2.1.12-1.dsc
N: Setting up lab in /tmp/NgxK6pfkcP ...
N: Processing 1 packages...
N: 
N: Processing source package mailman (version 1:2.1.12-1) ...
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 50, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 51, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 52, INDEX line 1.
Use of uninitialized value $_ in substitution (s///) at 
/usr/share/lintian/collection/file-info line 53, INDEX line 1.
Use of uninitialized value $_ in printf at 
/usr/share/lintian/collection/file-info line 54, INDEX line 1.
internal error: command failed with error code 123
warning: collect info file-info about package mailman: 512
warning: skipping check of source package mailman
N: Removing /tmp/NgxK6pfkcP ...
$ lintian -v --keep-lab mailman_2.1.12-1.dsc
N: Setting up lab in /tmp/4mm5vNSwz0 ...
N: Processing 1 packages...
N: 
N: Processing source package mailman (version 1:2.1.12-1) ...
W: mailman source: debhelper-but-no-misc-depends mailman

I'm quite lost here...


Thijs


signature.asc
Description: This is a digitally signed message part.

Bug#515689: duplicate-font-file X also in ttf-aenigma, bad advice?

[Thijs Kinkhorst]

Package: lintian
Version:

Hi,

On my package 'serendipity' I now get the following Lintian warning:

W: serendipity: duplicate-font-file 
usr/share/serendipity/www/plugins/serendipity_event_spamblock/chumbly.ttf 
also in ttf-aenigma
N: 
N:This package appears to include a font file that is already provided by
N:another package in Debian. It should instead depend on the relevant font
N:package. If the application in this package loads the font file by name,
N:you may need to include a symlink pointing to the file name of the font
N:in its Debian package.
N:
N:Severity: normal, Certainty: possible
N: 

This may sound fair at first, but since the ttf-aenigma package has an 
installed size of 25 MB and my package needs just that one font, so depending 
on ttf-aenigma does not seem like such a good idea afterall.

Since the package is that huge, perhaps Lintian should not be encouraging 
maintainers to start depending on it when they have just one font from it in 
their packages. Or do you think I should rather add an override instead?


cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.

Bug#515690: embedded-javascript-library: not so certain

[Thijs Kinkhorst]

Package: lintian
Version: 2.2.0
Severity: minor

Hi,

In my package 'serendipity' I get the following warning:

W: serendipity: embedded-javascript-library 
usr/share/serendipity/www/templates/default/YahooUI/treeview/YAHOO.js
[...]
N:Severity: normal, Certainty: certain

This YAHOO.js is a completely different file from the yahoo.js shipped in the 
libjs-yui package; the Lintian code does matching only based on filenames. In 
this case I think the certainty: certain is not that appropriate, as 
filenames are hardly unique.


thanks,
Thijs


signature.asc
Description: This is a digitally signed message part.

Bug#498617: package with only I tags is displayed on normal report and PTS

[Thijs Kinkhorst]

Package: lintian
Version: 1.24.4
Severity: minor


Hi,

I have a package (php-net-socket) that currently just has two info-level 
lintian tags. On the page
http://lintian.debian.org/maintainer/[EMAIL PROTECTED]
it is listed in the bulleted list near the top but the anchor doesn't go 
anywhere.

Also the PTS links to this page as if it had something to say about the 
package which it doesn't.


cheers,
Thijs



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494723: command-with-path-in-maintainer-script: misparses command

[Thijs Kinkhorst]

Package: lintian
Version: 1.24.3
Severity: minor

Hi,

This is a cosmetic issue only. The test command-with-path-in-maintainer-script 
misparses the command it detected. See e.g. in phpmyadmin:

command-with-path-in-maintainer-script

* postrm:12 /usr/sbin/lighty
* postinst:13 /usr/sbin/lighty

While the actual command used is /usr/sbin/lighty-enable-mod.

As a side note, we currently use a construct commonly advised, like this:
if [ -x /usr/sbin/lighty-enable-mod ] ; then
/usr/sbin/lighty-enable-mod phpmyadmin auth
fi
do you recommend to replace the part inside the if with
`which lighty-enable-mod` then?


cheers,
Thijs


pgpOvieaoe1pR.pgp
Description: PGP signature

Bug#487515: lintian.debian.org: doesn't show results for package in contrib

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.28
Severity: minor

Hi,

My lintian.debian.org page doesn't list the package 'msttcorefonts' I
maintain which is in contrib. I guess this is because contrib and
non-free packages are not checked. I see no good reason to not do that;
other Debian QA tools list those packages aswell.

This is somewhat between a wishlist to add contrib packages and a bug
since my page in some way suggests that the report is comprehensive
which it's not, so I've chosen the 'minor' middle road.


cheers,
Thijs

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils   2.17-3The GNU assembler, linker and bina
ii  diffstat   1.43-2produces graph of changes introduc
ii  dpkg-dev   1.13.25   package building tools for Debian
ii  file   4.17-5etch3   Determines file type using magic
ii  gettext0.16.1-1  GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libparse-debianchangel 1.0-1 parse Debian changelogs and output
ii  man-db 2.4.3-6   The on-line manual pager
ii  perl [libdigest-md5-pe 5.8.8-7etch3  Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#471751: False positive: unknown-section base

[Thijs Kinkhorst]

On Thursday 20 March 2008 00:21, Russ Allbery wrote:
 lintian is slightly ahead of Policy, but base is gone; ftpmaster has
 already moved all packages out of base and it will be removed from the
 next Policy release.  Please change the section.

Good to know, I've updated the package. Thanks,

Thijs


pgplr0RIst4kk.pgp
Description: PGP signature

Bug#471751: False positive: unknown-section base

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.46

Hi,

Lintian produces a warning unknown-section base, but the description of that 
warning is:

|The `Section:' field in this package's control file is not one of the
|sections in use on the ftp archive. Valid sections are currently admin,
|base, comm, devel, doc, editors, electronics, embedded, games, gnome,
|graphics, hamradio, interpreters, kde, libdevel, libs, mail, math, misc,
|net,  news, oldlibs, otherosfs, perl, python, science, shells, sound,
|tex, text, utils, web, and x11.

|The section name should be preceded by `non-free/' if the package is in
|the non-free distribution, and by `contrib/' if the package is in the
|contrib distribution.  

|Refer to Policy Manual, section 2.4 for details. 

As you can see, base is clearly there, and so is it in policy 2.4.

The list of affected packages is here:
http://lintian.debian.org/reports/tags/unknown-section.html


cheers,
Thijs


pgp8ATWcvX6TN.pgp
Description: PGP signature

Bug#460964: issues unknown unknown-interpreter tag

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.42

Hi!

Lintian issues the tag unknown-interpreter at two places:

./checks/infofiles:189: tag unknown-interpreter, $script, $interp;
./checks/menus:563: tag unknown-interpreter, $script, $interp;

But this tag is not a known tag resulting in:

Tried to issue unknown tag unknown-interpreter

So interestingly enough the interpretation of the unknown-interpreter tag is 
unknown itself.


Thijs


pgpbiwf4aR8n1.pgp
Description: PGP signature

Bug#460966: uninitialized values when having empty prerm script

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.42
Severity: minor

Hi,

I accidentally created a zero-byte 'debian/prerm' script in my package. That 
of course was not intentional or useful, but the output of lintian contained 
quite some 'uninitialized value's and was unclear as to the source of this 
problem:

Now running lintian...
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/menus line 548.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/menus line 548.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/menus line 553.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/menus line 558.
Tried to issue unknown tag unknown-interpreter
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/infofiles line 174.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/infofiles line 174.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/infofiles line 179.
Use of uninitialized value in pattern match (m//) 
at /usr/share/lintian/checks/infofiles line 184.
Tried to issue unknown tag unknown-interpreter

Making $interp in checks/menus initialized to 'unknown' when reading IN 
fails would eliminate the warnings and give the appropriate tag.

Same goes for checks/infofiles. [alert! code duplication]


Thijs


pgpMdOsdQJ3c8.pgp
Description: PGP signature

Re: New lintian pages available for testing

[Thijs Kinkhorst]

On Thu, January 3, 2008 10:00, Lars Wirzenius wrote:
 That would mean that it gets harder to get one or the other version of
 the page: it's no longer enough to just go to the page, you also have to go
 click on something else as well. For something that is a simple report
 page, I don't think that's warranted. For DDPO it's more warranted, given
 that DDPO is more of an application, and also seems to be able to
 remember your state. For lintian, I don't think it's worth the
 complication.

You could make it start out with the full output if you request it with a
?full=1 URL parameter. That could satisfy both wishes.


Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: New lintian pages available for testing

[Thijs Kinkhorst]

Hi Russ,

On Thursday 3 January 2008 01:16, Russ Allbery wrote:
 http://lintian.debian.org/reports-testing/

This looks good in general, it's a clear improvement over what we have.

 * The HTML pages are now templatized (using Text::Template).  The core of
   many of the pages is still generated by some not-horribly-pleasant Perl
   embedded in the templates, but all of the transformation from data to
   HTML should now be in the templates so that someone can modify them
   independent of the main script.

Great. Would this include the capability to wrap different tag severities in 
different HTML-tags so each could get their own CSS class?

 * There are two reports for each maintainer.  The one under maintainer,
   matching the existing URL scheme, shows errors and warnings as before.
   The one under full shows all tags, including info and overridden tags.
   The tag index links to the full page, and the maintainer index links to
   both.

I was thinking that this could be better implemented by generating one page 
per maintainer with all tags, and that I and O are hidden elements by 
default. A link on the page would then just toggle the visibility of that CSS 
class (just like the legend at the top of the DDPO).

The advantage is less output to generate and no need to reload a page between 
toggles. A possible drawback could be that the E/W pages get a larger 
filesize. Are there significantly more I+O tags so that the 'full' pages are 
getting very large?

thanks,
Thijs


pgpRL95sr8IsS.pgp
Description: PGP signature

Bug#455211: improperly encoded and symbols in descriptions

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.38
Severity: minor
Tags: patch

Hi!

The new malformed-override tag introduces some unencoded  and  in the 
description, making the text unreadable. This has only partially been fixed 
in SVN. Attached patch fixes that description fully, plus some other 
instances of unencoded  and  I could find.


Thijs
diff -Nur lintian-1.23.38/checks/debconf.desc lintian-1.23.39/checks/debconf.desc
--- lintian-1.23.38/checks/debconf.desc	2007-10-15 03:29:28.0 +0200
+++ lintian-1.23.39/checks/debconf.desc	2007-12-09 10:45:57.0 +0100
@@ -181,7 +181,7 @@
  .
  Since error types were added after debconf-2.0, one cannot use the normal
  debconf-2.0 alternative to allow for cdebconf or other implementations.
- Instead, use ttdebconf (= 1.4.69) | cdebconf (= 0.39)/tt.
+ Instead, use ttdebconf (gt;= 1.4.69) | cdebconf (gt;= 0.39)/tt.
  .
  All versions of debconf back to etch support error templates, but the
  debconf released with sarge didn't, so this dependency is still helpful
diff -Nur lintian-1.23.38/checks/debhelper.desc lintian-1.23.39/checks/debhelper.desc
--- lintian-1.23.38/checks/debhelper.desc	2007-04-28 06:42:25.0 +0200
+++ lintian-1.23.39/checks/debhelper.desc	2007-12-09 10:46:11.0 +0100
@@ -22,7 +22,7 @@
 
 Tag: package-lacks-versioned-build-depends-on-debhelper
 Type: info
-Info: If a package sets debhelper's compatibility version to = 5,
+Info: If a package sets debhelper's compatibility version to gt;= 5,
  either via DH_COMPAT, or via debian/compat, or via dh_testversion
  (which is deprecated), it should declare a versioned Build-Depends on
  the needed version of debhelper.
@@ -92,7 +92,7 @@
 Type: info
 Info: The source package requests dh_python compatibility level 2 (or
  higher) in ttdebian/pycompat/tt but doesn't depend on a new enough
- debhelper.  A Build-Depends on debhelper (= 5.0.37.2) is required for
+ debhelper.  A Build-Depends on debhelper (gt;= 5.0.37.2) is required for
  this support.
  .
  All versions of debhelper back to etch support this, but the debhelper
diff -Nur lintian-1.23.38/checks/files.desc lintian-1.23.39/checks/files.desc
--- lintian-1.23.38/checks/files.desc	2007-12-04 20:37:27.0 +0100
+++ lintian-1.23.39/checks/files.desc	2007-12-09 10:44:58.0 +0100
@@ -30,9 +30,9 @@
  installed into the old /usr/X11R6/lib/X11/fonts path may not be seen by
  the X server.
  .
- If the package uses imake, it must build-depend on xutils-dev (=
+ If the package uses imake, it must build-depend on xutils-dev (gt;=
  1:1.0.2-2) for the correct paths. If it uses dh_installxfonts to handle X
- font installation, it must build-depend on debhelper (= 5.0.31).
+ font installation, it must build-depend on debhelper (gt;= 5.0.31).
 Ref: policy 11.8.5
 
 Tag: package-installs-file-to-usr-x11r6-bin
@@ -48,14 +48,14 @@
  successfully. However, such a package will be left in an inconsistent
  state and may orphan files when the compatibility link goes away.
  .
- If the package uses imake, it must build-depend on xutils-dev (=
+ If the package uses imake, it must build-depend on xutils-dev (gt;=
  1:1.0.2-2) for the correct paths.
 Ref: policy 11.8.7
 
 Tag: file-in-usr-something-x11-without-pre-depends
 Type: info
 Info: Packages that install files into /usr/include/X11 or /usr/lib/X11
- should pre-depend on at least x11-common (= 1:7.0.0).  These directories
+ should pre-depend on at least x11-common (gt;= 1:7.0.0).  These directories
  used to be symlinks and installing files in them while they are still
  symlinks will put files in the wrong locations and cause stranded files
  and other problems.  x11-common is responsible for converting the
@@ -74,7 +74,7 @@
  .
  Programs that use GNU autoconf and automake are usually easily configured
  at compile time to use /usr/ instead of /usr/X11R6/.  Packages that use
- imake must build-depend on xutils-dev (= 1:1.0.2-2) for the correct
+ imake must build-depend on xutils-dev (gt;= 1:1.0.2-2) for the correct
  paths.
 Ref: policy 11.8.7
 
@@ -527,7 +527,7 @@
 Type: error
 Ref: policy 11.8.6
 Info: Packages that install files into the /etc/X11/Xresources/ directory must
- declare a conflict with xbase ( 3.3.2.3a-2); if this is not done it is
+ declare a conflict with xbase (lt;lt; 3.3.2.3a-2); if this is not done it is
  possible for the installing package to destroy a previously-existing
  /etc/X11/Xresources file which had been customized by the system
  administrator.
diff -Nur lintian-1.23.38/checks/lintian.desc lintian-1.23.39/checks/lintian.desc
--- lintian-1.23.38/checks/lintian.desc	2007-12-04 09:25:33.0 +0100
+++ lintian-1.23.39/checks/lintian.desc	2007-12-09 10:42:01.0 +0100
@@ -61,9 +61,9 @@
 Info: Lintian discovered an override entry with an invalid format.  An
  override entry should have the format:
  .
-   package[ type]: tag[ extra ...]
+   lt;packagegt;[ lt;typegt;]: lt;taggt;[ lt;extragt; ...]
  .
- where package is the package name, the optional 

Bug#454239: symlink-should-be-relative: warning instead of error

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.36
Severity: minor
Tags: patch

Hi!

In my package mailman, I have converted two symlinks from relative to 
absolute. The relative symlinks gave trouble for a number of different users 
that had symlinked the targets themselves, and linking to relative links 
gives different results than linking to absolute ones.

Lintian gave me the following error:
E: mailman: symlink-should-be-relative var/lib/mailman/locks /var/lock/mailman

However, Policy does allow absolute symlinks, it just recommends in general to 
use relative ones:

 10.5 Symbolic links

 In general, symbolic links within a top-level directory should be relative,
 and symbolic links pointing from one top-level directory into another
 should be absolute. (A top-level directory is a sub-directory of the root
 directory /.)

I read that as it's ok if you have a good reason. Therefore, I think a 
lintian warning would be more appropriate than an error. Attached patch 
implements this change. Please consider applying it.

Thanks,
Thijs
diff -Nru /tmp/coFypZabC0/lintian-1.23.36/checks/files.desc /tmp/lnog9si6LE/lintian-1.23.37/checks/files.desc
--- /tmp/coFypZabC0/lintian-1.23.36/checks/files.desc	2007-10-16 04:54:52.0 +0200
+++ /tmp/lnog9si6LE/lintian-1.23.37/checks/files.desc	2007-12-04 09:33:54.0 +0100
@@ -276,7 +276,7 @@
 Ref: policy 10.5
 
 Tag: symlink-should-be-relative
-Type: error
+Type: warning
 Info: Symlinks to files which are in the same top-level directory, should be
  relative according to policy (i.e., files within /usr, should be relative
  etc., while files from /usr to /etc should be absolute)
diff -Nru /tmp/coFypZabC0/lintian-1.23.36/testset/tags.binary /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.binary
--- /tmp/coFypZabC0/lintian-1.23.36/testset/tags.binary	2007-10-15 22:03:17.0 +0200
+++ /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.binary	2007-12-04 09:34:29.0 +0100
@@ -33,7 +33,7 @@
 E: binary: su-wrapper-without--c /usr/share/menu/binary:3 sux
 E: binary: suidregister-used-in-maintainer-script postinst
 E: binary: symlink-contains-spurious-segments usr/share/doc/binary/html/ch2.html ../html/./ch1.html
-E: binary: symlink-should-be-relative usr/share/doc/binary/html/ch3.html /usr/share/doc/binary/htm/ch1.html
+W: binary: symlink-should-be-relative usr/share/doc/binary/html/ch3.html /usr/share/doc/binary/htm/ch1.html
 E: binary: unstripped-binary-or-object ./usr/bin/hello
 I: binary source: xs-vcs-header-in-debian-control xs-vcs-browser
 I: binary: arch-dep-package-has-big-usr-share
diff -Nru /tmp/coFypZabC0/lintian-1.23.36/testset/tags.filenames /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.filenames
--- /tmp/coFypZabC0/lintian-1.23.36/testset/tags.filenames	2007-10-16 04:58:34.0 +0200
+++ /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.filenames	2007-12-04 09:34:16.0 +0100
@@ -23,7 +23,7 @@
 E: filenames: symlink-has-too-many-up-segments usr/lib/filenames/symlink2wrong ../../../../etc/symlink
 E: filenames: symlink-should-be-absolute usr/lib/filenames/symlink10wrong ../../..
 E: filenames: symlink-should-be-absolute usr/lib/filenames/symlink1wrong ../../../etc/symlink
-E: filenames: symlink-should-be-relative usr/lib/filenames/symlink3wrong /usr/lib/filenames/symlink2
+W: filenames: symlink-should-be-relative usr/lib/filenames/symlink3wrong /usr/lib/filenames/symlink2
 E: filenames: use-of-compat-symlink usr/bin/X11/
 E: filenames: use-of-compat-symlink usr/bin/X11/testxbin
 I: filenames: file-in-usr-something-x11-without-pre-depends usr/include/X11/
diff -Nru /tmp/coFypZabC0/lintian-1.23.36/testset/tags.libbaz /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.libbaz
--- /tmp/coFypZabC0/lintian-1.23.36/testset/tags.libbaz	2007-06-18 12:17:51.0 +0200
+++ /tmp/lnog9si6LE/lintian-1.23.37/testset/tags.libbaz	2007-12-04 09:34:23.0 +0100
@@ -15,7 +15,7 @@
 E: libbaz1: unstripped-binary-or-object ./usr/lib/libbaz3.so.1.0.3b
 E: libbaz1: unstripped-binary-or-object ./usr/lib/libfoo2.so.1.0.3b
 E: libbaz2: postinst-must-call-ldconfig usr/lib/libbaz2.so.1.0.3b
-E: libbaz2: symlink-should-be-relative usr/share/doc/libbaz2/changelog.gz /usr/share/doc/lintian/changelog.gz
+W: libbaz2: symlink-should-be-relative usr/share/doc/libbaz2/changelog.gz /usr/share/doc/lintian/changelog.gz
 I: libbaz1: no-md5sums-control-file
 I: libbaz1: possible-non-posix-code-in-maintainer-script postinst:6 '[ -d /usr/doc -a ! -e /usr/doc/$PKG -a '
 I: libbaz1: possible-non-posix-code-in-maintainer-script prerm:5 '[ \( $1 = upgrade -o $1 = remove \) -a '


pgp7WHHodlppm.pgp
Description: PGP signature

Bug#449257: warn on non-increasing changelog version numbering

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.36
Severity: wishlist

Hi,

I received a package from a sponsoree that contained two changelog sections 
both with the exact same version number, which was obviously a mistake but 
lintian didn't catch it.

I assume that all version numbers in the changelog should be strictly 
monotonically increasing (for every version holds version  
previous-version). Maybe there is some case I did no think of, but to me 
anything other seems nonsensical and hence a mistake.

I propose that lintian checks the version numbers in the changelog to satisfy 
this constraint.


thanks,
Thijs


pgptSkUNxTerj.pgp
Description: PGP signature

Bug#448677: lintian: Please include copyright-contains-dh_make-todo-boilerplate

[Thijs Kinkhorst]

Hi,

 (BTW, isn't lintian maintained in a public $VCS? Being able to
 debcheckout it would be great. ;-))

Yes it is, I've added the following Vcs-* fields to debian/control just now:

Vcs-Svn: http://svn.wolffelaar.nl/lintian/trunk/
Vcs-Browse: http://svn.wolffelaar.nl/wsvn/lintian/


Thijs


pgp5m2nV90fOv.pgp
Description: PGP signature

Bug#438860: debconf-error-requires-versioned-depends too strict

[Thijs Kinkhorst]

Package: lintian
Severity: wishlist
Version: 1.23.34

Hi,

The debconf-error-requires-versioned-depends test is triggered on my package:

I: msttcorefonts: debconf-error-requires-versioned-depends 
msttcorefonts/baddldir

Its description says:

N:   Since error types were added after debconf-2.0, one cannot use the
N:   normal debconf-2.0 alternative to allow for cdebconf or other
N:   implementations. Instead, use debconf (= 1.4.69) | cdebconf (=
N:   0.39).

Well, I have this dependency:
debconf (= 1.4.69) | cdebconf
which seems quite enough to me since cdebconf was at 0.74.2 in sarge already.


Thijs


pgpRzixBzJSdF.pgp
Description: PGP signature

Bug#437925: source-nmu-has-incorrect-version-number mentions old binNMU style

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.34
Severity: minor
Tags: patch

Hi,

The description for source-nmu-has-incorrect-version-number reads:

N:   A source NMU should have a Debian revision of '-x.x'. This is to
N:   prevent stealing version numbers from the maintainer (and the -x.x.x
N:   version numbers are reserved for binary-only NMU's).

The part about the binNMU version numbers is outdated. Since the new syntax is 
not really relevant to that explanation, I've attached a patch that just 
removes it.

thanks,
Thijs
diff -Nru checks/nmu.desc /tmp/5hA7sfZUxl/lintian-1.23.35/checks/nmu.desc
--- checks/nmu.desc.old	2007-03-17 07:57:00.0 +0100
+++ checks/nmu.desc	2007-08-14 22:23:25.0 +0200
@@ -21,8 +21,7 @@
 Tag: source-nmu-has-incorrect-version-number
 Type: warning
 Info: A source NMU should have a Debian revision of '-x.x'. This is to prevent
- stealing version numbers from the maintainer (and the -x.x.x version numbers
- are reserved for binary-only NMU's).
+ stealing version numbers from the maintainer.
  .
  Maybe you didn't intend this upload to be a NMU, in that case, please
  doublecheck that the most recent entry in the changelog is byte-for-byte


pgpqeHo716Y4S.pgp
Description: PGP signature

Bug#434744: Downgrade source-contains-CVS-dir to info

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.31
Severity: wishlist

Hi,

I'm getting the following warnings for one of my packages:
  W: phpgedview source: source-contains-CVS-dir places/IDN/CVS
  W: phpgedview-places binary: package-contains-CVS-dir 
usr/share/phpgedview/www/places/IDN/CVS/

While I can and will handle the second one inside the packaging, making sure 
that it doesn't get installed, I'm not so sure about the first one.

I've reported it upstream, but they haven't released a new version in ages. It 
seems to me I have the following options:
1) Repack upstream source;
2) Add an override.

Both are not appropriate in my opinion: I shouldn't repack the source for 
removing one dir, and adding an override for this doesn't seem right since 
it's a real bug(let), but not in the packaging.

To me it seems more logical to make the test of 'info' level. You cannot 
always influence what upstream does and repacking for this is not 
appropriate. It's just something you should send upstream, but no more.


Thijs


pgpnnBe2Or8pI.pgp
Description: PGP signature

Bug#424164: lintian: don't complain about README/LICENSE files in zope Products

[Thijs Kinkhorst]

reopen 424164
thanks

Hi,

  + [RA] Don't warn about LICENSE files in Zope products, since they may
be used for runtime display.  (Closes: #424164)

I'm wondering about the background of this change. I've read the original 
request, which was that some applications like to display the licence in 
their program.

phpMyAdmin does the same and I've solved this by simply 
symlinking /usr/share/doc/phpmyadmin/copyright. This file is then displayed 
just as expected in the application when someone clicks on License.

You might argue that there's a case to be made to display the licence only in 
its original form, as distributed by upstream. While I don't subscribe to 
that view, if you do it's not something specific to Zope.

The way I see it there's two possible solutions:
1) Zope just symlinks the /usr/share/doc/zope/copyright file. That seems like 
the best option to me. Or is that not possible?
2) It's considered a feature that software displays the original licence as 
distributed by upstream. In that case, I don't think it's needed to make 
special exceptions for Zope; if it is desirable for Zope it may be desirable 
for other applications just as well.

In both cases I don't think the current change is appropriate, so I've taken 
the liberty to reopen the bug for now.


Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#424164: lintian: don't complain about README/LICENSE files in zope Products

[Thijs Kinkhorst]

On Tuesday 5 June 2007 17:07, Bernd Zeimetz wrote:
 we're talking about zope template files here, not just a stupid text
 file living somewhere. It doesn't make sense to read a Zope template on
 it's own, and it's not possible to drop a simple text file into it's
 place instead. *.pt files are part of the web-application.

I guess I've misunderstood the bug then. The changelog message said they may
be used for runtime display which I read as are displayed for an interested 
user to see what licence the program is under. Would you mind to give me an 
example when such a template would be used?


Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#423171: possible-missing-colon-in-closes should not check ancient entires

[Thijs Kinkhorst]

On Thursday 10 May 2007 17:28, Russ Allbery wrote:
  I suggest to only check the topmost changelog entry, as some other tests
  already do aswell if I remember correctly.

 None that I could find, and I couldn't see a way of doing that without
 some structural changes, although I could look again. 

This was only from the top of my head, so I could be mistaken.

 However, it's not  correct that only the top-most changelog entries are
relevant.

That's true in some cases, and indeed the .changes file might address that. 
But I wonder whether there will be many more false positives, i.e. 
many-year-old changelog entries being flagged, than bugs that are missed in 
those cases. At least I would see flagging a non-current changelog entry that 
way as a false positive.

What course of action do you suggest? Fix the changelog retroactively?


thanks,
Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#406349: lintian: Some tests contain 'usr-doc' which should be 'usr-share-doc'

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.27
Severity: minor
Tags: patch

Hi,

The following tests:

usr-doc-symlink-points-outside-of-usr-doc
usr-doc-symlink-without-dependency
usr-doc-symlink-to-foreign-package
cannot-check-whether-usr-doc-symlink-points-to-foreign-package

still have names with 'usr-doc', while they actually do not test for
stuff under /usr/doc but /usr/share/doc. This is of course fine other
than that the tag names should be updated. Attached is a patch to do
that.

I've left the following two tests, which actually *do* relate to
/usr/doc:

postinst-should-not-set-usr-doc-link
doc-base-file-references-usr-doc

thanks,
Thijs

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils   2.17-3The GNU assembler, linker and bina
ii  diffstat   1.43-2produces graph of changes introduc
ii  dpkg-dev   1.13.25   package building tools for Debian
ii  file   4.17-5Determines file type using magic
ii  gettext0.16.1-1  GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libparse-debianchangel 1.0-1 parse Debian changelogs and output
ii  man-db 2.4.3-5   The on-line manual pager
ii  perl [libdigest-md5-pe 5.8.8-7   Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information
diff -Nru /tmp/Ty38Mr2fv0/lintian-1.23.27/checks/copyright-file 
/tmp/IFe0sL7AhL/lintian-1.23.28/checks/copyright-file
--- /tmp/Ty38Mr2fv0/lintian-1.23.27/checks/copyright-file   2006-08-19 
01:12:38.0 +0200
+++ /tmp/IFe0sL7AhL/lintian-1.23.28/checks/copyright-file   2007-01-10 
15:56:46.0 +0100
@@ -73,7 +73,7 @@

# check if this symlink references a directory elsewhere
if ($link =~ m,^(\.\.)?/,) {
-   tag usr-doc-symlink-points-outside-of-usr-doc, $link;
+   tag usr-share-doc-symlink-points-outside-of-usr-share-doc, 
$link;
last;
}

@@ -96,7 +96,7 @@
 defined($known_essential{$link}))) {
# no, it does not.
 
-   tag usr-doc-symlink-without-dependency, $link;
+   tag usr-share-doc-symlink-without-dependency, $link;
last;
}
}
@@ -110,10 +110,10 @@
# yes, everything is ok.
} else {
# no, it is not.
-   tag usr-doc-symlink-to-foreign-package, $link;
+   tag usr-share-doc-symlink-to-foreign-package, $link;
}
} else {# no, source is not available
-   tag 
cannot-check-whether-usr-doc-symlink-points-to-foreign-package, ;
+   tag 
cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package, ;
}

# everything is ok.
diff -Nru /tmp/Ty38Mr2fv0/lintian-1.23.27/checks/copyright-file.desc 
/tmp/IFe0sL7AhL/lintian-1.23.28/checks/copyright-file.desc
--- /tmp/Ty38Mr2fv0/lintian-1.23.27/checks/copyright-file.desc  2006-04-13 
07:15:53.0 +0200
+++ /tmp/IFe0sL7AhL/lintian-1.23.28/checks/copyright-file.desc  2007-01-10 
15:57:23.0 +0100
@@ -46,7 +46,7 @@
  tt/usr/share/common-licenses/GPL/tt instead.
 Ref: policy 12.5
 
-Tag: usr-doc-symlink-without-dependency
+Tag: usr-share-doc-symlink-without-dependency
 Type: error
 Info: If the package installs a symbolic link /usr/share/doc/ipkg1/i -gt;
  ipkg2/i, then ipkg1/i has to depend on ipkg2/i with the same
@@ -57,7 +57,7 @@
  directory within ipkg1/i and copy the copyright file into that directory.
 Ref: policy 12.5
 
-Tag: usr-doc-symlink-to-foreign-package
+Tag: usr-share-doc-symlink-to-foreign-package
 Type: error
 Info: If the package installs a symbolic link /usr/share/doc/ipkg1/i -gt;
  ipkg2/i, then ipkg1/i and ipkg2/i must both come from the same
@@ -67,7 +67,7 @@
  within ipkg1/i and copy the copyright file to that directory.
 Ref: policy 12.5
 
-Tag: cannot-check-whether-usr-doc-symlink-points-to-foreign-package
+Tag: cannot-check-whether-usr-share-doc-symlink-points-to-foreign-package
 Type: info
 Info: There is a symlink /usr/share/doc/ipkg1/i -gt; ipkg2/i
  in your package. This means that ipkg1/i and ipkg2/i must
@@ -103,7 +103,7 @@
  file. Please update the reference (the licenses are installed
  uncompressed).
 
-Tag: usr-doc-symlink-points-outside-of-usr-doc
+Tag: usr-share-doc-symlink-points-outside-of-usr-share-doc
 Type: error
 Info: The /usr/share/doc/ipkg/i symbolic link is pointing to a directory
  outside of tt/usr/share/doc/tt.
diff -Nru 

Bug#394104: lintian: Use of uninitialized value in concatenation in checks/fields

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.25
Severity: minor

Hi,

Lintian outputs a warning when checking update-manager_0.42.2ubuntu22-5.dsc
as available from the archive:

$ lintian update-manager_0.42.2ubuntu22-5.dsc
E: update-manager source: missing-build-dependency python | python-dev |
python-all-dev
Use of uninitialized value in concatenation (.) or string at
/usr/share/lintian/checks/fields line 754.
E: update-manager source: malformed-python-version all, = 2.4

Attached is the same run with debug output.


Thijs

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils   2.17-3The GNU assembler, linker and bina
ii  diffstat   1.43-2produces graph of changes introduc
ii  dpkg-dev   1.13.24   package building tools for Debian
ii  file   4.17-4Determines file type using magic
ii  gettext0.15-2GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libparse-debianchangel 1.0-1 parse Debian changelogs and output
ii  man-db 2.4.3-4   The on-line manual pager
ii  perl [libdigest-md5-pe 5.8.8-6.1 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information
N: Lintian v1.23.25
N: Lintian root directory: /usr/share/lintian
N: Configuration file: /etc/lintianrc
N: Laboratory: 
N: Archive directory: 
N: Distribution: 
N: Default unpack level: 1
N: Architecture: any
N: 
N: Setting up lab in /tmp/VQQdVsvCf4 ...
N: Processing 1 packages...
N: Selected action: check
N: Requested unpack level: 1
N: Requested data to collect: 
override-file,copyright-file,file-info,debian-readme,debfiles,init.d,md5sums,changelog-file,diffstat,source-control-file,scripts,objdump-info,menu-files,doc-base-files
N: Selected checks: 
manpages,huge-usr-share,files,menus,debian-readme,rules,md5sums,scripts,version-substvars,debhelper,shared-libs,etcfiles,debconf,po-debconf,standards-version,copyright-file,debdiff,control-file,nmu,menu-format,deb-format,description,control-files,init.d,binaries,conffiles,spelling,changelog-file,fields,cruft,infofiles
N: 
N: Processing source package update-manager (version 0.42.2ubuntu22-5) ...
N: Base directory in lab: /tmp/VQQdVsvCf4/source/update-manager
N: Current unpack level is 0
N: Unpacking package to level 1 ...
N: Current unpack level is 1
N: Unpacking package to level 2 ...
N: /usr/share/lintian/unpack/unpack-srcpkg-l2 
/tmp/VQQdVsvCf4/source/update-manager
N: Collecting info: override-file ...
N: Current unpack level is 2
N: Collecting info: debfiles ...
N: Current unpack level is 2
N: Collecting info: diffstat ...
N: Current unpack level is 2
N: Collecting info: source-control-file ...
N: Current unpack level is 2
N: Running check: rules ...
N: Current unpack level is 2
N: Running check: version-substvars ...
N: Current unpack level is 2
N: Running check: debhelper ...
N: Current unpack level is 2
N: Running check: po-debconf ...
N: Current unpack level is 2
N: Running check: standards-version ...
N: Current unpack level is 2
N: Running check: debdiff ...
N: Current unpack level is 2
N: Running check: control-file ...
N: Current unpack level is 2
N: Running check: nmu ...
N: Current unpack level is 2
N: Running check: fields ...
E: update-manager source: missing-build-dependency python | python-dev | 
python-all-dev
Use of uninitialized value in concatenation (.) or string at 
/usr/share/lintian/checks/fields line 754.
E: update-manager source: malformed-python-version all, = 2.4
N: Current unpack level is 2
N: Running check: cruft ...
N: Decreasing unpack level to 1 (removing files) ...
N: Removing /tmp/VQQdVsvCf4 ...

Bug#388824: select-with-translated-default-field may be a bit overzealous

[Thijs Kinkhorst]

On Tue, 2006-09-26 at 21:20 -0700, Russ Allbery wrote:
  Attached is a patch that checks source packages instead of binary
  packages. There are different advantages for this solution:

This sounds good, thanks Thomas for the patch and Russ for swiftly
applying it.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#388824: select-with-translated-default-field may be a bit overzealous

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.24
Severity: minor

Hello,

Our package uses a translated DefaultChoice field in the debconf
templates, exactly as described in DevRef 6.5.4.4.

Lintian triggers a warning on this: select-with-translated-default-field.
Since the warning doesn't apply, I'm overriding it. However, the warning
is triggered for every occurrence in every po file. That means I'm now
putting two overrides per language in our lintian-overrides file:

select-with-translated-default-field mailman/site_languages hu.utf-8
select-with-translated-default-field mailman/default_server_language hu.utf-8
select-with-translated-default-field mailman/site_languages ja.utf-8
select-with-translated-default-field mailman/default_server_language ja.utf-8
[...]

I think you'll get my point: we've got 13 languages already, equals 26
overrides, and I expect this to only grow. Adding two overrides for
every language that we add is not ideal.

So my question here is: is there a better way to solve this? Some ideas,
in my order of preference, I don't know what's best or possible from
your point of view though:

1) Remove the test altogether. If I do not mark DefaultChoice as
   translatable, then it will not appear in the .po file template, so
   what's the chance of someone translating it nonetheless? And if they
   do, it will be ignored so no harm done. I'm wondering what the test
   tries to accomplish.

2) If the test is actually needed, make sure it does not trigger if
   DefaultChoice was marked as translatable. If it's marked as such, the
   package maintainer intends for it to be translated.

3) Trigger the warning only once for a package.

4) Make the warning overridable categorically, i.e. I add
   select-with-translated-default-field mailman/site_languages and all
   those warnings will be overridden regardless of the last bit.


By the way, thanks for your maintenance of Lintian, it really helps to
make Debian packages better!


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#382477: too-long-extended-description-in-templates: rather fix the tool than condense a description

[Thijs Kinkhorst]

reassign 382477 developers-reference
retitle 382477 Sect 6.5.3.2: rather fix the tool than condense a description
thanks

On Fri, 2006-08-11 at 07:28 -0700, Russ Allbery wrote:
 Thijs Kinkhorst [EMAIL PROTECTED] writes:
 
  Package: lintian
  Version: 1.23.22
 
  Hello,
 
  On the mailman package I received this lintian warning:
 
  W: mailman: too-long-extended-description-in-templates 
  mailman/queue_files_present
  N:
  N:   Some debconf interfaces cannot deal very well with descriptions of
  N:   more than about 20 lines, so try to keep the extended description
  N:   below this limit.
  N:
  N:   Refer to Developers Reference, section 6.5.3.2 for details.
  N:
 
  I've checked that description, and it's quite long but also very
  informational to the admin. I could condense it, but I feel that
  throwing away useful information because of some anonymous tool cannot
  deal with it is not right: we should fix that bug instead of setting an
  arbitrary 20-line limit on descriptions.
 
  The description remains vague as where exactly the problem originates.
  I'm not sure what it is that imposes the number 20 and why our 26 is
  too much.
 
 In this case, I'm going to refer you to the Developer's Reference
 maintainers, since I don't think the lintian maintainers have the
 expertise to know why this rule is present.  We picked up that rule
 straight from the devref, and presumably the team that developed those
 rules had justification for it at the time and knowledge of which debconf
 interfaces had problems.
 
 On the lintian side, I'd much prefer to continue to check for exactly what
 the devref says, since that way it's a lot easier to remain consistent.
 So if this is wrong, the devref should really change.

Ok, fine. I'm reassigning this to the developer's reference then.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#382477: too-long-extended-description-in-templates: rather fix the tool than condense a description

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.22

Hello,

On the mailman package I received this lintian warning:

W: mailman: too-long-extended-description-in-templates 
mailman/queue_files_present
N:
N:   Some debconf interfaces cannot deal very well with descriptions of
N:   more than about 20 lines, so try to keep the extended description
N:   below this limit.
N:
N:   Refer to Developers Reference, section 6.5.3.2 for details.
N:

I've checked that description, and it's quite long but also very
informational to the admin. I could condense it, but I feel that
throwing away useful information because of some anonymous tool cannot
deal with it is not right: we should fix that bug instead of setting an
arbitrary 20-line limit on descriptions.

The description remains vague as where exactly the problem originates.
I'm not sure what it is that imposes the number 20 and why our 26 is
too much.


Thanks for considering.

Thijs


signature.asc
Description: This is a digitally signed message part

Bug#368206: lintian: Should not warn for writing style in untranslatable templates

[Thijs Kinkhorst]

reopen 368206
thanks

Hi,

When trying to resolve some lintian warnings of a package, I encountered
this same situation: the template is for internal use and thus has no
description, however I still get a warning:

E: dbconfig-common: no-template-description 
dbconfig-common/internal/reconfiguring
W: dbconfig-common: malformed-question-in-templates 
dbconfig-common/internal/reconfiguring

Lintian suggests to put the text for internal use in the description
to satisfy lintian, but we don't agree that this is a good thing: the
description was omitted on purpose because it serves no use and would
only end up in the .po files as an extra translatable string.

Adding 'for internal use' will indeed silence lintian but adds an extra
string to translate for all languages while that string is not useful at
all, meaning more cruft and more work for all involved.

I suggest not to complain about templates with no description at all,
since these can be assumed to be internal.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#374167: lintian: [unnoticed] debian/conpyright: It was downloaded from fill in http/ftp site

[Thijs Kinkhorst]

 The following line goes unnoticed by Lintian:
 
It was downloaded from fill in http/ftp site
 
 lintian should check if there is 'http://', 'ftp://' URL and warn if
 no valid looking URL link was found on the upload line.

Well, there's of course a large list of protocols one could use to
download that, but more importantly, to my understanding the
debian/copyright file is freeform. I've got a package where the upstream
source was mailed to the packager, and there's nothing that prevents
that.

*If* you want to check for this (I think it's overkill) you should match
on that fill in http/ftp site string because then you're sure that
someone didn't edit the template. In any other case you can't judge if
it's right or wrong.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#377616: lintian: Mention Lintian version in standard page footer

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.22
Severity: wishlist
Tags: patch

Hello,

Here's a simple patch to mention the Lintian version used in the
standard page footer of the HTML output.


Thijs

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages lintian depends on:
ii  binutils 2.17-1  The GNU assembler, linker and bina
ii  diffstat 1.41-1  produces graph of changes introduc
ii  dpkg-dev 1.13.22 package building tools for Debian
ii  file 4.17-2  Determines file type using magic
ii  gettext  0.14.6-1GNU Internationalization utilities
ii  intltool-debian  0.34.2+20060621 Help i18n of RFC822 compliant conf
ii  libparse-debianchangelog 1.0-1   parse Debian changelogs and output
ii  man-db   2.4.3-3 The on-line manual pager
ii  perl [libdigest-md5-perl 5.8.8-6 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information
diff -ur lintian-1.23.22.orig/reporting/html_reports 
lintian-1.23.22/reporting/html_reports
--- lintian-1.23.22.orig/reporting/html_reports 2005-08-12 21:49:07.0 
+0200
+++ lintian-1.23.22/reporting/html_reports  2006-07-10 13:16:56.0 
+0200
@@ -58,7 +58,7 @@
 div style=font-size: smaller
 pPlease send all comments about these web pages to
 A HREF=mailto:[EMAIL PROTECTED]Lintian maintainer/A./p
-pPage last updated: $timestamp/p
+pPage last updated: $timestamp using Lintian $LINTIAN_VERSION/p
 /div
 /BODY/HTML
 EOT_EOT_EOT

Bug#375638: lintian: deb-created-with-broken-tar: typos and tar version clarification

[Thijs Kinkhorst]

Package: lintian
Version: 1.23.21
Severity: minor
Tags: patch

Hello,

The explanation of deb-created-with-broken-tar says that some versions of
tar are broken. I've added to the message a summary of which (Debian) versions
this concerns.

Furthermore the description has two typos, s/make/makes/,
s/build/built/. See attached patch.


Thijs

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages lintian depends on:
ii  binutils 2.17-1  The GNU assembler, linker and bina
ii  diffstat 1.41-1  produces graph of changes introduc
ii  dpkg-dev 1.13.22 package building tools for Debian
ii  file 4.17-2  Determines file type using magic
ii  gettext  0.14.6-1GNU Internationalization utilities
ii  intltool-debian  0.34.2+20060621 Help i18n of RFC822 compliant conf
ii  libparse-debianchangelog 1.0-1   parse Debian changelogs and output
ii  man-db   2.4.3-3 The on-line manual pager
ii  perl [libdigest-md5-perl 5.8.8-6 Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information
diff -ur lintian-1.23.21.orig/checks/deb-format.desc 
lintian-1.23.21/checks/deb-format.desc
--- lintian-1.23.21.orig/checks/deb-format.desc 2004-04-14 01:14:17.0 
+0200
+++ lintian-1.23.21/checks/deb-format.desc  2006-06-27 12:12:06.0 
+0200
@@ -9,10 +9,11 @@
 Tag: deb-created-with-broken-tar
 Type: error
 Info: The binary package was created with a broken version of tar.
- Some versions of tar contain a bug, which make the resulting .deb broken. On
- unpack, some filenames are going to be corrupted.
+ Some versions of tar, most notably 1.13.92-1 to 1.13.93-1 contain a bug,
+ which makes the resulting .deb broken. On unpack, some filenames are going
+ to be corrupted.
  .
- This package was build with such a version of tar, and the mentioned filename
+ This package was built with such a version of tar, and the mentioned filename
  is corrupted. Refer to Debian bug #230910 for more information, or simply
  update your tar-version and rebuild.
 

Bug#348864: please check if man page is in right section

[Thijs Kinkhorst]

Collin Watson [EMAIL PROTECTED] wrote:
 All that said, while I can think of valid examples where a program is in
 bin with a man page in section 8, I can't think of any valid examples
 where a program is in sbin with a man page in section 1. I think a check
 for the latter would probably be reasonable enough.

The package 'piuparts' is such an example. I first filed that as a bug
against the program, but the maintainer convinced me that he was indeed
doing the right thing:

| I'm not sure that is correct. man(7) describes section 8 as System
| management commands, and piuparts is not such a command, it is a
| programmer tool. Or at least that is what it is in my mind. Therefore, I
| find that section 1 is correct, even if it can be usefully run only by
| root.


Thijs



signature.asc
Description: This is a digitally signed message part

Bug#350114: Please add ubuntu upload targets to frontend/lintian

[Thijs Kinkhorst]

Reinhard Tartler [EMAIL PROTECTED] wrote:
 in order to get rid of this patch in ubuntu, please include it in the
 next lintian upload. Attached the patch we have in ubuntus lintian.

That doesn't seem right. We can assume that someone packaging on a
Debian system (i.e. running lintian from Debian) is preparing a Debian
package, and someone on Ubuntu, running Ubuntu's lintian, is targetting
Ubuntu.

Therefore, the check as-is is valid, and quite useful: if someone is
confused and puts an Ubuntu target in a Debian package, this will be
detected by lintian.


Thijs


signature.asc
Description: This is a digitally signed message part

Bug#324490: lintian.debian.org: Typo in lintian 404 page

[Thijs Kinkhorst]

Package: lintian
Severity: minor

Lintian.debian.org 404 pages (Either there's no record of packages from
that maintainer...) have a small error at their footer: the mailto:
link contains two wrongly-escaped quotes (\) and there's an extra
quote at the end of the document.


Thijs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#317277: copyright-lists-upstream-authors-with-dh_make-boilerplate is overly nitpicky - please remove

[Thijs Kinkhorst]

On Fri, July 8, 2005 19:29, Goswin von Brederlow wrote:
 It points out a minor shortcomming in the phrasing of the text. Like
 people reporting typos or spelling mistakes. This is certainly no RC
 bug but something that is easily fixable and should be fixed non the
 less.

Well, it's not even a spelling mistake or a shortcoming. The text is valid
- only it could have been a tiny bit shorter. I don't see what value that
adds at all.

Let's remember that Lintian is a policy checker. Too many, too detailed
tests will reduce its usefulness and yielding spurious warnings erodes the
value of a warning. I could think of a thousand more tests (like
useful-spelled-as-usefull ;) but it's just not appropriate to add those to
lintian in my opinion.


regards,
Thijs



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]