Bug#322291: lintian: invalid-arch-string-in-source-relation triggers on amd64
Package: lintian
Version: 1.23.10
Severity: normal
Tags: patch
(Bug severity because this is an incorrect error.)
A Build-Depends entry like:
libopenafs-dev [alpha amd64 hppa i386 ia64 powerpc s390 sparc]
triggers invalid-arch-string-in-source-relation because of amd64. The
reported information also refers the user to policy 5.6.7, which is the
section on the Package field. I assume that 5.6.8 was intended.
The attached patch (against 1.23.11) downgrades a non-standard
architecture in a source dependency to info, following the precedent of
the Architecture field.
I didn't repeat the architecture list from non-standard-architecture
in the new non-standard-arch-in-source-relation tag; it seemed like yet
one more thing to keep in sync and didn't seem particularly necessary
there.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.30
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages lintian depends on:
ii binutils 2.16.1-2 The GNU assembler, linker and bina
ii diffstat 1.39-1produces graph of changes introduc
ii file 4.12-1Determines file type using magic
ii gettext0.14.5-2 GNU Internationalization utilities
ii intltool-debian0.30+20040213 Help i18n of RFC822 compliant conf
ii man-db 2.4.3-1 The on-line manual pager
ii perl [libdigest-md5-perl] 5.8.7-3 Larry Wall's Practical Extraction
lintian recommends no packages.
-- no debconf information
diff -rupN lintian-1.23.11.orig/checks/fields lintian-1.23.11/checks/fields
--- lintian-1.23.11.orig/checks/fields 2005-07-11 06:08:12.0 -0700
+++ lintian-1.23.11/checks/fields 2005-08-09 23:28:57.0 -0700
@@ -448,8 +448,11 @@ if ($type eq source) {
my ($d_pkg, $d_version, $d_arch, $rest,
$part_d_orig) = @$part_d;
for my $arch (@{$d_arch-[0]}) {
- tag
invalid-arch-string-in-source-relation, $arch [$field: $part_d_orig]
- unless ($known_archs{$arch}
|| $arch eq any || $arch eq all);
+ if ($non_standard_archs{$arch})
{
+ tag
non-standard-arch-in-source-relation, $arch [$field: $part_d_orig];
+ } elsif (!$known_archs{$arch}
$arch ne any $arch ne all) {
+ tag
invalid-arch-string-in-source-relation, $arch [$field: $part_d_orig]
+ }
}
tag
depends-on-build-essential-package-without-using-version, $d_pkg [$field:
$part_d_orig]
diff -rupN lintian-1.23.11.orig/checks/fields.desc
lintian-1.23.11/checks/fields.desc
--- lintian-1.23.11.orig/checks/fields.desc 2005-06-27 02:10:02.0
-0700
+++ lintian-1.23.11/checks/fields.desc 2005-08-09 23:23:49.0 -0700
@@ -379,11 +379,16 @@ Info: The package declares a depends on
Tag: invalid-arch-string-in-source-relation
Type: error
-Ref: policy 5.6.7
+Ref: policy 5.6.8
Info: The architecture string in the source relation does not follow policy.
A common cause of this is a comma in the arch, i.e. [i386, m68k], it should
be [i386 m68k].
+Tag: non-standard-arch-in-source-relation
+Type: info
+Info: The architecture string in the source relation is one of the
+ architectures still waiting to be included in the archive.
+
Tag: depends-on-build-essential-package-without-using-version
Type: error
Info: The package declares a depends on a build essential package without
Bug#321564: lintian: shouldn't warn package-name-doesnt-match-sonames on non-library packages
tags 321564 patch
thanks
I just ran into this myself with a package containing Apache modules and
spent some time fixing it. Here's a patch that only warns for SONAMEs of
libraries found in /lib, /usr/lib, or /usr/X11R6/lib. This may still miss
some interesting cases, but I think it will catch 95% of the useful cases
that the test should catch with far fewer false positives.
--- lintian-1.23.11/checks/binaries.orig2005-07-23 16:09:01.0
-0700
+++ lintian-1.23.11/checks/binaries 2005-08-16 23:02:16.0 -0700
@@ -113,7 +113,20 @@
}
close(IN);
-my @sonames = keys %SONAME;
+# For the package naming check, filter out SONAMEs where all the files are
+# at paths other than /lib, /usr/lib, or /usr/X11R6/lib. This avoids false
+# positives with plugins like Apache modules, which may have their own
+# SONAMEs but which don't matter for the purposes of this check.
+sub lib_soname_path {
+my (@paths) = @_;
+foreach my $path (@paths) {
+return 1 if $path =~ m%^(\.?/)?lib/[^/]+$%;
+return 1 if $path =~ m%^(\.?/)?usr/lib/[^/]+$%;
+return 1 if $path =~ m%^(\.?/)?usr/X11R6/lib/[^/]+$%;
+}
+return 0;
+}
+my @sonames = grep { lib_soname_path (@{$SONAME{$_}}) } keys %SONAME;
tag several-sonames-in-same-package, @sonames if @sonames 1;
my $match_found = 0;
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332770: Should check for editor's cruft
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.8 Severity: wishlist Lintian should check for editor's left-about cruft such as semantic.cache files, *~ files, .foo.swp files, etc etc, both in sources and in binary packages. Similar to the recent conversation about CVS directories, the source package check should probably only be done in the diff or the tarball for native packages, not on files from .orig.tar.gz. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)
Justin Pryzby [EMAIL PROTECTED] writes: Package: lintian Severity: wishlist I am including a list of 73 packages which happened to be installed on my laptop which contain a maintscript with the fragment: # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. Maybe this is a debhelper bug? What's wrong with that? It's documentation in the version of the script that's in the source package. I have several packages with postinst scripts that have sections like: # dh_installdeb will replace this with shell code automatically # generated by other debhelper scripts. #DEBHELPER# This refers to the #DEBHELPER# token. In any case, I would like to request that lintian includes a check to ensure that new packages do not contain that text. Please don't. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344609: lintian: better build-depends-indep check
Package: lintian
Version: 1.23.14
Severity: normal
Tags: patch
While sponsoring a package (cdrbq), I noticed that lintian complaints about
build-depends-without-arch-dep for Build-Depends: dpatch. However, if one
uses the makefile include method for integrating dpatch, dpatch does have
to be installed to run make clean and therefore should be in Build-Depends.
Similar problems exist for cdbs and dbs.
While I was fixing this, I noticed that the regex in the existing check is
insufficiently conservative and:
Build-Depends: debhelper (= 4.0.0), python-dev ( 2.3)
will be judged as fine because \(.+?\) will pick up everything to the end
of the line. +? just stops matching at the earliest point it *can* and
not change the success of the overall match; if it has to match farther
in order to make the whole expression match, it will.
This patch pulls the database of things to look for out into a global
variable, makes the check easier to extend down the road, and also adds
a special case for yada packages (allowing yada in Build-Depends if the
debian/packages file exists). Applying this patch will therefore also
close #321135.
I considered also ensuring that the packages discovered were listed in
Build-Depends, but I think that's too likely to turn up false positives
(if, for instance, someone did something sneaky and made the inclusion
of the dpatch makefile fragment conditional). But it wouldn't be too
hard to add if it turns out to be a good idea.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages lintian depends on:
ii binutils 2.16.1cvs20051214-1 The GNU assembler, linker and bina
ii diffstat 1.41-1 produces graph of changes introduc
ii dpkg-dev 1.13.11 package building tools for Debian
ii file 4.15-2 Determines file type using magic
ii gettext 0.14.5-2GNU Internationalization utilities
ii intltool-debian 0.34.1+20050828 Help i18n of RFC822 compliant conf
ii libparse-debianchang 1.0-1 parse Debian changelogs and output
ii man-db 2.4.3-3 The on-line manual pager
ii perl [libdigest-md5- 5.8.7-10Larry Wall's Practical Extraction
lintian recommends no packages.
-- no debconf information
diff -ru lintian-1.23.14/checks/fields lintian-new/checks/fields
--- lintian-1.23.14/checks/fields 2005-08-12 16:44:18.0 -0700
+++ lintian-new/checks/fields 2005-12-23 17:23:11.0 -0800
@@ -29,6 +29,28 @@
use Tags;
use Util;
+# Certain build tools must be listed in Build-Depends even if there are no
+# arch-specific packages because they're required in order to run the clean
+# rule. (See Policy 7.6.) The following is a list of pairs of packages and
+# regular expressions that, if they match anywhere in the debian/rules file,
+# say that this package is allowed in Build-Depends.
+my @global_depends = (
+ [ cdbs = '^include\s+/usr/share/cdbs/' ],
+ [ dbs = '^include\s+/usr/share/dbs/' ],
+ [ debhelper = '^include\s+/usr/share/cdbs/1/rules/debhelper.mk' ],
+ [ dpatch = '^include\s+/usr/share/dpatch/' ]
+);
+
+# Similarly, these pairs of packages and regexes say that if the regex matches
+# in one of clean, build-arch, or binary-arch, this package is allowed in
+# Build-Depends.
+my @rule_depends = (
+ [ debhelper = '^\s+dh_.+' ]
+);
+
+# Note that yada is handled as a special case, based on the existence of
+# debian/packages.
+
sub run {
my $pkg = shift;
@@ -403,23 +425,34 @@
my $build_depends = BD;
close BD;
- my $uses_dh = 0;
+ my @allowed;
if (not open (RULES, debfiles/rules)) {
fail(cannot read debfiles/rules: $!);
} else {
my $target = none;
local $/ = \n; #Read this linewise
while (RULES) {
+ for my $rule (@global_depends) {
+ if ($_ =~ /$rule-[1]/) {
+ push (@allowed,
$rule-[0]);
+ }
+ }
$target = $1 if (/^(\S+):/);
- if (/^\s+dh_.+/ grep ($_ eq $target,
qw(clean binary-arch build-arch)) or
-
m#^include\s+/usr/share/cdbs/1/rules/debhelper.mk#) {
-
Re: lintian: r532 - in trunk: checks debian testset testset/cdbs-test testset/cdbs-test/debian
djpig [EMAIL PROTECTED] writes:
+ $allowed{yada}++ if -e debfiles/packages;
+ my @packages = split /\s*,\s*/, $build_depends;
+ foreach my $pkg (@packages) {
+ my ($name) = ($pkg =~ /^(\S+)/);
+ unless ($allowed{$name}) {
+ tag build-depends-without-arch-dep, ;
+ last;
+ }
FWIW, the reason why I did yada as an odd special case rather than putting
it in the %allowed hash is because I had some thought of eventually using
the %allowed hash to make sure that there were build dependencies on all
of those packages (although as mentioned, there may be false positives).
If that's ever done, the existence of debian/packages probably shouldn't
trigger a check for a build-depends on yada as that's even more prone to
false positives than the others.
Thank you for adding a test! I was trying to figure out how to do that
and couldn't quite see, so I can use this as an example in the future.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349272: lintian: understand DH_COMPAT := level
Package: lintian
Version: 1.23.15
Severity: minor
Tags: patch
Ran into this while fixing some older Debian Perl packages. Someone set
DH_COMPAT with:
export DH_COMPAT := 3
and lintian didn't see it. The attached patch allows an optional : before
the = for both methods of setting DH_COMPAT, since to make it means the
same thing. (?= is really a bug since something set in the environment
shouldn't change the compatibility level of the package, so I intentionally
didn't allow that case.)
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Versions of packages lintian depends on:
ii binutils 2.16.1cvs20051214-1 The GNU assembler, linker and bina
ii diffstat 1.41-1 produces graph of changes introduc
ii dpkg-dev 1.13.11 package building tools for Debian
ii file 4.15-2 Determines file type using magic
ii gettext 0.14.5-2GNU Internationalization utilities
ii intltool-debian 0.34.1+20050828 Help i18n of RFC822 compliant conf
ii libparse-debianchang 1.0-1 parse Debian changelogs and output
ii man-db 2.4.3-3 The on-line manual pager
ii perl [libdigest-md5- 5.8.7-10Larry Wall's Practical Extraction
lintian recommends no packages.
-- no debconf information
--- lintian-1.23.15/checks/debhelper.orig 2006-01-19 06:11:59.0
-0800
+++ lintian-1.23.15/checks/debhelper2006-01-21 14:30:30.0 -0800
@@ -93,11 +93,11 @@
$seencommand = 1;
$needbuilddepends = 1;
$needtomodifyscripts = 1;
-} elsif (/^\s*export\s+DH_COMPAT\s*=\s*(\d+)/) {
+} elsif (/^\s*export\s+DH_COMPAT\s*:?=\s*(\d+)/) {
$needversiondepends = $1;
} elsif (/^\s*export\s+DH_COMPAT/) {
$needversiondepends = $dhcompatvalue if $dhcompatvalue;
-} elsif (/^\s*DH_COMPAT\s*=\s*(\d+)/) {
+} elsif (/^\s*DH_COMPAT\s*:?=\s*(\d+)/) {
$dhcompatvalue = $1;
}
}
Re: Bug#109642: debhelper: Simplify inclusion of lintian overrides
Raphael Hertzog [EMAIL PROTECTED] writes: Package: debhelper Version: 5.0.16 Followup-For: Bug #109642 I'm ccing the current maintainers of lintian so that they can give their opinion on this bug. Given the opinions voiced in this bug log here's what I suggest : Overrides should only be placed with care, that's right, that doesn't mean we shouldn't make it easy. Instead we should warn the maintainer that the override is meant as a temporay measure until lintian is fixed. Er, well, except there are places where an override is simply needed and probably will be needed indefinitely. Examples from packages I maintain: krb5-kdc: non-standard-dir-perm Yes, that's the directory that contains the server's keys, and it should indeed be mode 700. krb5-user: setuid-binary Yup, that's the whole point of ksu. libkrb53: package-name-doesnt-match-sonames And if it ever changes SONAMEs, we'll fix this, but changing the package name of a Priority: standard package just to make the package name match the SONAME isn't a particularly great idea. :) openafs-client: postinst-uses-db-input In order to figure out whether we need to prompt or not, we have to check if the local cell is already configured in the standard CellServDB file, which we don't have access to until after the package is installed. Ugly, but I don't see a better alternative. Another excellent example is a case where the man pages for a package are in a different package that the first depends on, which is a long-standing known limitation of lintian that probably won't be fixed (at least any time soon). I'm fairly careful about making sure that all my packages are lintian-clean, and the above overrides are not just temporarily workarounds for broken lintian checks. They deal with cases where it would be very hard for lintian to have enough information to understand that this isn't the place for that diagnostic. It's certainly not that difficult to install lintian overrides manually, but I must admit I would like to see a debhelper tool to make it simpler and more like the other control files of the package. Maybe the dh_lintian script should systematically print a prominent warning in the build log asking the maintainer to check wether the lintian override is still needed ? Ew. But IMHO, debian/package.lintian-overrides should automatically be installed in /usr/share/lintian/overrides/package by one of the dh_* script (maybe dh_lintian could be folded into a generic dh_ script?). Please make it just package.lintian; the directory listing of the debian directory is bad enough as is without adding more extra-wide filenames. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349273: lintian: allow quilt in Build-Depends
Russ Allbery [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.15 Severity: minor Tags: patch Not sure if anyone has started using quilt for an arch-independent package yet, but since the debian/rules glue works the same as dpatch, it too must be present during debian/rules clean and therefore must be in Build-Depends rather than Build-Depends-Indep. May as well head off the problem in advance. The attached patch adds that case. Bleh, sorry, missing comma. --- lintian-1.23.15/checks/fields.orig 2006-01-05 00:17:59.0 -0800 +++ lintian-1.23.15/checks/fields 2006-01-21 15:35:17.0 -0800 @@ -38,7 +38,8 @@ [ cdbs = '^include\s+/usr/share/cdbs/' ], [ dbs = '^include\s+/usr/share/dbs/' ], [ debhelper = '^include\s+/usr/share/cdbs/1/rules/debhelper.mk' ], - [ dpatch = '^include\s+/usr/share/dpatch/' ] + [ dpatch = '^include\s+/usr/share/dpatch/' ], + [ quilt = '^include\s+/usr/share/quilt/' ] ); # Similarly, these pairs of packages and regexes say that if the regex matches -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347510: lintian: menu-icon-not-in-xpm-format needs updating/removing
Paul Wise [EMAIL PROTECTED] writes: On Sat, 2006-01-21 at 15:03 -0800, Russ Allbery wrote: Aha, so that is where it is. Well, lintian should probably make what it is referring to more apparent, something like Debian Menu System 3.7. It does currently say menu 3.7; does that still seem unclear to you? To me, that suggested the menu policy. menu manual 3.7 would clarify that. Ah, sorry, I understand. That seems unobjectionable to me; I'll commit a patch. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xfonts-* overrides
Ryan Underwood [EMAIL PROTECTED] writes: I've been taking over an xfonts-package, namely xfonts-dosemu. It appears that an override is necessary to avoid installs-file-to-usr-X11R6 warnings. But a font package does this by necessity. Should this warning be suppressed for any package beginning with xfonts- ? I suggest just adding the override and not worrying about this right now, since the entire world of X directory structure is going to change once X11R7 and the modular tree hit unstable. My guess is that the eventual fallout of that will be that X fonts can be installed in /usr/share. It's probably not worth modifying lintian in the meantime. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warnings/errors
Michael Stilkerich [EMAIL PROTECTED] writes:
I'd like to hand back this one *SCNR* :-) (just kidding)
Changing
lintian-1.23.15/checks/scripts:312
if (system($interpreter -n unpacked/$filename /dev/null 21)) {
to
if (system($interpreter -n \unpacked/$filename\ /dev/null 21)) {
fixes the problem. Should I report a bug anyway?
No, I've got it. Preparing a patch now that fixes this a bit more
comprehensively (the above still fails if the filename contains ).
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Patch review for objdump fixes around debugging data
===
--- testset/debug/debian/control(revision 0)
+++ testset/debug/debian/control(revision 0)
@@ -0,0 +1,34 @@
+Source: debug
+Section: utils
+Priority: optional
+Maintainer: Russ Allbery [EMAIL PROTECTED]
+Build-Depends: debhelper (= 5.0.0)
+Standards-Version: 3.6.2
+
+Package: hello
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Test for external debugging information
+ lintian regression test for external debugging file handling.
+
+Package: hello-dbg
+Priority: extra
+Architecture: any
+Depends: hello (= ${Source-Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: Test for external debugging information
+ lintian regression test for external debugging file handling.
+
+Package: libhello0
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Test for external debugging information
+ lintian regression test for external debugging file handling.
+
+Package: libhello0-dbg
+Section: libdevel
+Priority: extra
+Architecture: any
+Depends: libhello (= ${Source-Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: Test for external debugging information
+ lintian regression test for external debugging file handling.
Index: testset/debug/debian/changelog
===
--- testset/debug/debian/changelog (revision 0)
+++ testset/debug/debian/changelog (revision 0)
@@ -0,0 +1,6 @@
+debug (1.0) unstable; urgency=low
+
+ * Initial version.
+
+ -- Russ Allbery [EMAIL PROTECTED] Sat, 4 Mar 2006 21:31:06 -0800
+
Index: testset/debug/debian/copyright
===
--- testset/debug/debian/copyright (revision 0)
+++ testset/debug/debian/copyright (revision 0)
@@ -0,0 +1 @@
+Written Sat, 04 Mar 2006 21:30:01 -0800 by Russ Allbery [EMAIL PROTECTED].
Index: testset/debug/debian/rules
===
--- testset/debug/debian/rules (revision 0)
+++ testset/debug/debian/rules (revision 0)
@@ -0,0 +1,62 @@
+#!/usr/bin/make -f
+# Sample debian/rules that uses debhelper.
+# This file is public domain software, originally written by Joey Hess.
+
+export DH_COMPAT := 5
+
+build: build-stamp
+build-stamp:
+ dh_testdir
+ gcc -D_REENTRANT -fPIC -c libhello.c
+ gcc -o libhello.so.0.0 -shared -Wl,-soname,libhello.so.0 libhello.o
+ ln -s libhello.so.0.0 libhello.so
+ gcc -o hello hello.c -L. -lhello
+ touch build-stamp
+
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp *.o libhello.so.0.0
+ dh_clean
+
+install: build-stamp
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+ install -D hello $(CURDIR)/debian/hello/usr/bin/hello
+ install -D libhello.so.0.0 \
+ $(CURDIR)/debian/libhello0/usr/lib/libhello.so.0.0
+ ln -s libhello.so.0.0 \
+ $(CURDIR)/debian/libhello0/usr/lib/libhello.so.0
+
+# Build architecture-dependent files here.
+export DH_OPTIONS
+binary-arch: DH_OPTIONS=-a
+binary-arch: build-stamp install
+ dh_testdir
+ dh_testroot
+ dh_installchangelogs
+ dh_installdocs
+ DH_OPTIONS= dh_strip -phello --dbg-package=hello-dbg
+ DH_OPTIONS= dh_strip -plibhello0 --dbg-package=libhello0-dbg
+
+ # Now break a few things. Copy the debugging data into places it
+ # shouldn't be.
+ cp $(CURDIR)/debian/hello-dbg/usr/lib/debug/usr/bin/hello \
+ $(CURDIR)/debian/hello/usr/bin/hello.dbg
+ cp $(CURDIR)/debian/libhello0-dbg/usr/lib/debug/usr/lib/libhello.so.0.0
\
+ $(CURDIR)/debian/libhello0-dbg/usr/lib/libhello.so.dbg
+
+ dh_link
+ dh_compress
+ dh_fixperms
+ dh_makeshlibs
+ dh_installdeb
+ dh_shlibdeps
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+
+binary-indep:
+binary: binary-indep binary-arch
+.PHONY: binary binary-indep binary-arch build clean install
Property changes on: testset/debug/debian/rules
___
Name: svn:executable
+ *
Index: testset/debug/hello.c
===
--- testset/debug/hello.c (revision 0)
+++ testset/debug/hello.c (revision 0)
@@ -0,0 +1,9 @@
+#include stdlib.h
+#include libhello.h
+
+int
+main(void)
+{
+ hello();
+ exit(0);
+}
Index: testset/debug/libhello.c
===
--- testset/debug/libhello.c(revision 0)
+++ testset/debug/libhello.c(revision 0)
@@ -0,0 +1,7 @@
+#include stdio.h
+
+void
+hello(void)
+{
+ printf(Hello, World!\n);
+}
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian warnings/errors
Michael Stilkerich [EMAIL PROTECTED] writes: * Russ Allbery [EMAIL PROTECTED] [2006-02-09 11:37]: lintian has code specifically to recognize this situation. I'm not sure why it isn't working. Can I see the rules and control file for this package somewhere? sure, see attachment. I think the problem came up when I started to use dpatch - if you look for dh_clean in the clean target you won't find it, since dh_clean is called from the clean-patched target that clean depends on. This is the solution suggested by the dpatch documentation. Thanks, sorry about the delay. I've just committed an improvement, making lintian chase rules that clean, build-arch, and binary-arch depend on. It only knows how to chase rules forward, so your example works but something like: clean-patched: dh_clean clean: clean-patched will still fail, but hopefully that's unlikely. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352606: lintian: lintian-info -- Use of uninitialized value in split at /usr/bin/lintian-info line 51
Jari Aalto [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.15 Severity: normal Following error log in produced. Please investigate: $ echo E: fspanel; DH_COMPAT is greater than the major version of debhelper depended on. | lintian-info E: fspanel; DH_COMPAT is greater than the major version of debhelper depended on. Use of uninitialized value in split at /usr/bin/lintian-info line 51, line 1. Use of uninitialized value in exists at /usr/bin/lintian-info line 53, line 1. That's not a valid lintian message (no colon after the package name and no tag at all), so lintian-info should have just passed it along without further comment. I fixed the bug that produced the various warnings messages in Subversion. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350114: Please add ubuntu upload targets to frontend/lintian
Thijs Kinkhorst [EMAIL PROTECTED] writes: 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. Yeah, that was my reaction too -- I think this is one of those places where Debian and Ubuntu really want to be (slightly) distinct. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351324: lintian: incorrect tcl test
James R Van Zandt [EMAIL PROTECTED] writes: Russ - I'd rather still check the dependencies, though, so I'm trying to figure out what the right dependency is. I would expect the virtual tclx package to be the right dependency, but as you say, tclx8.4 doesn't provide /usr/bin/tcl. Do you have any idea why? It seems like it should; TclX has always provided the tcl binary in my experience. It's an upstream change. From the tclx8.4 README: TclX 8.4 differs from its predecessors in that it is based more on the idea of TclX as an extension to Tcl, and not an alternate environment. There is no TkX and no stand-alone shells are built. ...which is why I suggested the dependency check should be on tclx8.3. Aha, now I understand. Thank you for the explanation! I've applied a patch to fix the dependency lintian expects. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356307: lintian: wrong error messages for broken symlinks
Michael Spang [EMAIL PROTECTED] writes:
Package: lintian
Version: 1.23.15
Severity: normal
The following lintian error occured during the testing of a package I am
preparing:
E: firefox-greasemonkey: symlink-should-be-absolute
usr/lib/firefox/extensions/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
../../../../share/mozilla-extensions/greasemonkey
And, after making it absolute:
E: firefox-greasemonkey: symlink-should-be-relative
usr/lib/firefox/extensions/{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
/usr/share/mozilla-extensions/greasemonkey
The first of these is obviously wrong. After further testing I realized
that the symlink ascended one too many levels and was broken. Lintian
erronously reported that a broken relative symlink (which should be
relative) should be made absolute. It might be wise to add a broken
symlink error or warning.
I'm pretty sure lintian's behavior here is correct. That message isn't
because the symlink is broken; it's because of exactly the problem that
you discovered. It ascended one too many levels, which means that it was
actually a symlink to:
/share/mozilla-extensions/greasemonkey
Since the symlink was in /usr and was pointing to a file in /share, it
correctly triggered the lintian error about relative symlinks between
top-level directories.
When you changed it to an absolute symlink, you of course fixed where it
was pointing to, and lintian then complained that it should be relative.
The circumstances under which you arrived at the error ended up being
rather confusing, but I think that lintian was always telling you the
truth. lintian cannot in general warn about dangling symlinks since it's
not uncommon to have the target of the symlink provided by another package
(think development packages for shared libraries, for instance, but there
are other cases).
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350228: lintian: false positive package-uses-deprecated-debhelper-compat-version with cdbs
Jay Berkenbilt [EMAIL PROTECTED] writes:
Package: lintian
Version: 1.23.15
Severity: normal
Tags: patch
If a package uses cdbs and includes debhelper.mk, then it is using a
correct debhelper compatibility version of 4. If you don't have a
debian/compat file that contains 4 (which cdbs will create
automatically, but may not be in the original sources), you will a
warning such as this one:
W: tiff source: package-uses-deprecated-debhelper-compat-version 1
I believe a sensible fix is to simply recognize that the correct
dhcompatvalue is 4 if cdbs is in use. The lintian debhelper check
already makes other assumptions based on cdbs. This one-line patch
should do the job. It has the unfortunate property of hard-coding the
number 4 as the current debhelper compat version in another place, but
that's easily rectified if desirable.
This seems basically reasonable, at least as a starting point. The
obvious elaboration would be to choose this value based on a versioned
build dependency on cdbs, but I think we can wait on doing that until it
looks needed.
--- checks/debhelper~ 2006-01-19 09:11:59.0 -0500
+++ checks/debhelper 2006-01-27 21:58:02.671089168 -0500
@@ -93,6 +93,7 @@
$seencommand = 1;
$needbuilddepends = 1;
$needtomodifyscripts = 1;
+ $needversiondepends = $dhcompatvalue = 4;
} elsif (/^\s*export\s+DH_COMPAT\s*=\s*(\d+)/) {
$needversiondepends = $1;
} elsif (/^\s*export\s+DH_COMPAT/) {
This would cause any cdbs package that did have a debian/compat file to
produce warnings about conflicting versions. I don't think that's
correct; I think cdbs is happy to use the debian/compat file that you have
if that's what you want.
I'm going to apply a slightly different patch that doesn't set the compat
level from cdbs until towards the end, and only if no other setting of it
was found.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch review for objdump fixes around debugging data
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Sat, Mar 04, 2006 at 10:34:19PM -0800, Russ Allbery wrote: This is the largest patch I've written for lintian so far and it includes a new test suite package, so I'd rather someone else look it over before I just commit it. Could someone take a look when you get a chance and let me know if it's sane? Looks fine to me, I didn't actually test it, but nothing in the patch struck me as particularly odd. Strategy of fixing is also ok, I agree this would be the way to do it. I'd say, commit it, and let's see. Thanks for the review! Committed. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: calling update-menus from prerm
Michael Stilkerich [EMAIL PROTECTED] writes: I got yet another question. I'd like to call an update-menus --menumethod mymethod --remove in the prerm script in order to remove any files generated by the menu-method. I can't do this in the postrm script since I need another script of the package that is not a configuration file. Lintian complains that update-menus should probably be called from postrm, which is not possible in my case, but does not give an explanation of the reasons. Should I add an override for this one or is there really a good reason why one should not do this from prerm? I poked around, and my best guess is that update-menus checks to see if the package is still installed before removing it, so calling update-menus in the prerm means that it may not remove the menu entry of your package because the package is, at that point, still installed. Now, in practice, this will almost never be a problem. update-menus backgrounds itself until dpkg is done working (by checking the lock file) and then runs, and my guess is that dpkg will hold the lock file through running prerm and then postrm. So in practice, update-menus would start working after postrm anyway. The only case where I can see the wrong thing happening would be if dpkg died after running the prerm for your package but before removing your package, and did so in a way that caused it to not re-run the prerm when things were cleaned up. Seems rather unlikely. So, not really sure what to say in this case. It's probably worth asking the menu maintainer if calling it in prerm is safe and if the above logic is correct. If it is safe, we can change the lintian warning. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: foo++ failing test
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: We should leave the errors: it remains an error in the .dsc to have it multi-line. However, the way to specify uploaders in debian/control may now be multiline, which is useful, and not buggy. Maybe by the letter of the policy, don't know how it really refers to debian/control as opposed to .dsc, but if so the policy should be changed. debian/control is only automagically parsed by dpkg, which puts it folded in the .dsc, where it's automatically parsed by $therest. This sounds great. Thank you very much for taking care of this update! The Policy bug in question is #148194. It's somewhat difficult right now to say in Policy that folding is allowed for debian/control but not for .dsc and .changes, since right now the fields for all three are defined together and folding is said to only be allowed if the specific field description says it is. This area will require some restructuring to make an exception for debian/control. Sorry for not following up on this faster. I've been working hard on a new WebAuth release and haven't had time for much else in the past few days. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian release soon?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: It's been a while since the last release, and mainly thanks to the great work by Russ Allbery, we've got a 80-line changelog entry atm and a mere 18 bugs fixed. I've rolled and installed the current svn (which now passes its own testsuite again), and would like to see an upload happen sometime in the near future. Widespread testing will only seriously happen anyway after upload to unstable, but a bit of testing by people on this list would be neat. So, please stresstest current svn a bit, and in case there's no serious problems found, we should upload the package. We can't fix all bugs at once after all. Russ, feel free to change the first line in the changelog entry if it bothers you, I'm feeling low on entropy^Winspiration a.t.m. to write something seriously witty. Sounds fine to me. :) The only additional thing that I think would be cool to get into this release is the patch attached to the bug log for Bug#344269. Most of that patch is just adding test cases for a bunch of weird rexec under Perl conventions that have been seen in the wild and a fairly uncontroversial change to catch the rest of these in the script_is_evil_and_wrong check. The only controversial part is that the patch also bypasses the check for #! or ELF magic if the script passes script_is_evil_and_wrong, which is required for one of the magic entry points that Frank discovered and which apparently doesn't work if you put #!/bin/sh in front of it. It only works if the binary has no magic and therefore forces the kernel /bin/sh fallback. I'm not sure if we want to pass in lintian scripts that require that, although I believe it does work everywhere (although I'm not positive about the Hurd). I have an idea on how to solve Bug#344266 in a more thorough fashion, but that can wait for the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357839: [frontend] report unused overrides
Package: lintian Version: 1.23.15 Severity: wishlist The lintian frontend has options to ignore overrides and report which overrides are triggered, but no option to report which overrides don't trigger. Since people add overrides to work around lintian bugs from time to time, it would be good to have such an option to help with later cleanup. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages lintian depends on: ii binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina ii diffstat 1.41-1 produces graph of changes introduc ii dpkg-dev 1.13.16 package building tools for Debian ii file 4.15-2 Determines file type using magic ii gettext 0.14.5-2GNU Internationalization utilities ii intltool-debian 0.34.1+20050828 Help i18n of RFC822 compliant conf ii libparse-debianchang 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-3 The on-line manual pager ii perl [libdigest-md5- 5.8.8-2 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]
Re: Lintian release soon?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Thu, Mar 16, 2006 at 05:05:30AM +0100, Jeroen van Wolffelaar wrote: So, please stresstest current svn a bit, and in case there's no serious problems found, we should upload the package. We can't fix all bugs at once after all. I heard no comments, and the testset still works etc. I plan to release tonight or tomorrow or so, unless someone yells and wants some more testing/finds showstopper bugs. Certainly works for me. I've been holding off from doing anything to make sure we stabilize for a release. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: load custom checks from ~/.lintian/checks?
Michael Ablassmeier [EMAIL PROTECTED] writes: i just wondered how am i supposed to add my own checks to lintian. It seems the only way to do this (without beeing root) is to copy the stuff from /usr/share/lintian to $HOME and use the --root switch to change $LINTIAN_ROOT. I think it would be very nice if lintian could check ~/.lintian/checks for checks and load them, just like linda does. Attached is a (i guess pretty hackish patch) against trunk which does this. This seems like at least an idea worth considering. Could you submitt his and your patch as a wishlist bug report? I don't know about the other lintian developers, but I try really hard not to keep things sitting around in my inbox because then they nag at me and feel like clutter. If you put the patch into the BTS, it will be there each time I review current bugs to find something to work on. Thanks! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: load custom checks from ~/.lintian/checks?
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: Well, I agree such request are best filed as bugs immediately, for the same reasons you (Russ) cite, but I can already say that personally, I'm not really terribly fond of this idea. Lintian should IMHO really be a tool that has a reliable output, and that can be used as a base for structural QA work etc. An important requisite for this is that lintian output should be constant regardless of your environment. There is --root for development on lintian, testing out/using locally certain patches (including simply added checks). ~/.lintian/checks might be neat, but only addresses a small subset, because it can only add checks, and then only checks that don't need any sort of collector changes. --root actually allows any kind of adoption, and is very easy too (just a cp -a or even cp -sa and adding/modifying whatever pleases you). Hm, yes, those are both really good points. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347169: X metapackage dependency check now obsolete?
Josh Triplett [EMAIL PROTECTED] writes:
It looks like at least one package (showeq) depends on
x-window-system-core (also not for use in Depends),
The description of x-window-system-core explicitly says it's for use in
Depends, actually. It does say that it's for use in Depends for
meta-packages, but right now lintian doesn't really draw that
distinction.
and it could well happen that someone might take the lazy-but-wrong
approach and use the other packages for dependencies in the future;
thus, I think checking for x-window-system{,-core,-dev} and xorg in
the Depends and Build-Depends fields couldn't hurt. (Note that
Recommends or Suggests on such a package does not cause a problem.)
Yeah, I was thinking about doing at least that much, but I couldn't figure
out a good way around the meta-package depending on another meta-package
thing. Build-Depends is a bit more straightforward.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360216: lintian: maintainer-script-built-with-broken-debhelper-version fires in non-debhelper case
Marc Haber [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.16 Severity: normal maintainer-script-built-with-broken-debhelper-version is reported if the construct invoke-rc.d.*exit 0 is found in any maintainer script. In my case, this was not from debhelper, but the offending code was in the maintainer script from the package proper. The --info text should say how exactly the test was done, and that an outdated debhelper is not the only cause of this warning. I'm going to go ahead and change the tag to: maintainer-script-hides-init-failure instead to be more generic and note in the description the likely debhelper cause. Thanks for the report! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360217: lintian: should clean invocation environment
Marc Haber [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.16 Severity: normal I have CDPATH set in my environment. This causes cd to print the new working directory, which in turn confuses lintian's has-errors-from-man detector so that a bogus error is reported. lintian should clean its environment before doing any tests that use a shell. Good catch. Fixing this now, fairly comprehensively. You would have potentially had the same problem with one of the po-debconf checks, and you may have been seeing extraneous output in the collection phase from objdump-info. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360227: lintian: check for gksu in menu-command-not-in-package
Colin Watson [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.16 Severity: wishlist W: bum: menu-command-not-in-package /usr/share/menu/bum:4 /usr/bin/gksu Since gksu's really an adverb rather than something we normally expect to find in the package itself, I think it should be handled a bit like su-to-root (and kdesu should probably be the same, IIRC). I suggest that if the menu file uses gksu, then we should (a) check for a dependency on gksu, (b) check that the command following gksu is in the package. I agree that the lintian warning is wrong. However, why wouldn't using gksu or kdesu in this situation be a warning themselves since su-to-root knows how to invoke them when appropriate? My preferred fix would be to check for use of gksu, kdesu, or sux at the beginning of the command and, in that case, emit a different warning telling package maintainers to just use su-to-root. I suppose that may not do the right thing if the maintainer is really sure they want to force a *particular* interface, but is that something people are likely to want to do? It looks like the wrong thing to do for bum. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357636: shlib-without-PT_GNU_STACK-section check not valid for all arches?
Bastian, You provided a patch to lintian to check for executable stack that was integrated in 1.23.13. We got a bug report indicating that it may not be valid on all architectures. Could you take a look at Bug#357636 when you get a chance and comment? Thanks! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#131347: lintian could check for -dev package dependencies
Package: lintian Severity: wishlist There are many -dev packages which do not declare dependency on necessary -dev packages. It might be nice to issue warnings on lib*-dev packages which have Depends: line with no lib*-dev dependencies against those which are in Build-Depends. Thinking about this for a bit, I don't think this is something that would ever be useful to do, unfortunately. This approach would make the assumption that any lib*-dev package required to build a package containing a library should also be a dependency of the development version of the library. Putting aside whether it's worth keeping such a dependency only for static linking when the one library completely hides the usage of the other, this fails for large packages that produce multiple binary packages. Consider a package that builds a library that depends on nothing but libc and a separate binary package of executables that depend on both it and, say, LDAP libraries. The LDAP -dev package will be in Build-Depends, but the library -dev package should not depend on it. Since Build-Depends is for the whole source package, not broken out by resulting binary package, I think this idea is unfortunately unworkable. If other lintian developers agree, I think this bug should probably just be closed. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360711: lintian: [lintian-info] improve diagnostics of package-uses-deprecated-debhelper-compat-version
Jari Aalto [EMAIL PROTECTED] writes: The problem is that neither debian/compat exists or DH_COMPAT is defined int debian/rules. Which means that debhelper uses its default compatibility level of 1, which is deprecated. That's what the warning is trying to tell you in this case. One should either set DH_COMPAT or (preferred) create debian/compat when using debhelper. I'll adjust the message to make that clear. Please consider using message like: N: The debhelper compatibility version used by this package is N: marked as deprecated by the debhelper developer. You should N: really consider using a newer compatibility version. Possible N: causes: 1) content of debian/compat 2) DH_COMPAT is defined in N: debian/rules 3) debian/control::Buil-Depends does not include N: version number for debhelper, like (= 4.0.0) It was a little difficult to find out, that the problem lied in debian/control::Buil-Depends So far as I can tell from looking at the lintian source, Build-Depends cannot create or solve this problem. That's a different warning. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357636: shlib-without-PT_GNU_STACK-section check not valid for all arches?
Bastian Blank [EMAIL PROTECTED] writes: On Sun, Apr 02, 2006 at 05:52:36PM -0700, Russ Allbery wrote: You provided a patch to lintian to check for executable stack that was integrated in 1.23.13. We got a bug report indicating that it may not be valid on all architectures. Could you take a look at Bug#357636 when you get a chance and comment? Hmm, I just rechecked on which arches gcc generates this section always. It seems that this are: - alpha - i386 (this includes amd64) - m68k - powerpc - s390 - sparc On the others it seems to be optional. Thanks! I've updated the check accordingly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian.debian.org still at 1.23.12
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Thu, Mar 23, 2006 at 11:56:59PM +0100, Bill Allombert wrote: lintian.debian.org still use lintian 1.23.12. Is it possible to upgrade it to 1.23.15 ? Currently running for 1.23.16 (just uploaded). Will take a few days to complete, iirc. How did that go? I'm particularly curious to see what stderr you got, since I think we have the errors in #295072 under control at this point (although to really close that bug, we need to implement the capturing of lintian failures and transforming them into tags so that we can also figure out what package is affected). Also is there some concerted effort to report to the BTS the most serious problems found by lintian ? Unfortunately, this hasn't really been coming off the ground lately. I hope this can be done in the reasonable near future again, lintian accuracy has greatly improved lately. This is another project that I'd be interested in working on, although of course getting up-to-date lintian.debian.org output is a good first step for this. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of 1.23.17
lintian is a wonderfully relaxing thing to work on while on vacation in the beautiful Pacific Northwest. :) There are now quite a few fixes accumulated in Subversion (20 bug fixes, 85 lines of changelog) but probably no reason to upload before the last upload makes it into testing. The only bug that makes me wonder if we should reset the propagation into testing is the CDPATH bug with the man page check, which caused a bit of consternation. If someone else thinks we should upload before lintian propagates into testing, do say something. Regardless, changing too much between uploads isn't a good idea, so I'm going to slow down on committing actual fixes and go work on some other projects and on cleaning up the bug database a bit (retitling bugs, clearing out meaningless tags, that sort of thing). One thing that I have been noticing while working on a variety of checks is that lintian could use a richer set of library functions. There are now multiple check modules that load and test dependencies, for instance, and they all repeat themselves to some extent. Similarly, there are several checks that parse the index created by unpack-binpkg-l1 and they all do similar things. Maybe a good lintian 1.24 project would be some substantial refactoring and lifting common routines into the library. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian.debian.org still at 1.23.12
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: It crapped out near the end, the whole things is quite fragile anyway, so instead I've been playing today with some totally alternative approach of having a site like lintian.d.o, but then for potentially unlimited amount of type of checks, lintian and non-lintian. You can see results of lintian coming in to /org/qa.debian.org/rebuildtesting/pool (the 'rebuildtesting' name is legacy, it's wrong, but I didn't come up with a nice new name yet) on merkel, but there isn't a good web interface yet (or one at all). For lintian, it's probably for now easiest to actually reconstruct the lintian.log file from the current 'pool'. Bonus is that it can do unstable testing both, and across all archs, instead of just i386. Especially nice and important for checks like the one that checks for 'built-with-broken-debhelper'. It also makes it much much easier to run in parallel scripts with a svn checkout of lintian. This sounds great. This is the new approach that lets it work from an archive pulse as well? I'll announce to -qa later tonight a bit about the status of this, it's work in progress, but it's long overdue. Let me know if there's anything in particular I can help with. Faster lintian.debian.org results and a way to gather other checks into the same interface both sound fantastic, particularly given all those [external] wont-fix bugs against lintian that often look like good candidates for other tools that work in different ways than lintian does. Probably a good idea to have some decent registration, perhaps via usertags and stuff, not sure how to do so exactly... I'm myself not really going to get involved in that in the near future, but am definitely interested on the medium term :). Maybe I'll write something up if I get a chance. I have some policy stuff I want to do first, though. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: checks/rules returns
Russ Allbery [EMAIL PROTECTED] writes: checks/rules is now back, using the make -p suggestion from debian-devel a while back. Here are the details on how we run make: Unfortunately, it looks like running make just isn't something we can do. This set of flags *almost* works, except that make still runs shell commands in rules like: foo := $(shell echo foo testing) Doing that while checking a package seems like asking for trouble to me. So, I'm taking out the make part (and unfortunately therefore the overall syntax checking) and just doing a simple parse of the makefile directly in Perl. I think that should be sufficient still to catch most of the things we're concerned with, including missing rules. (As before, many of these checks will be skipped if the makefile includes any other makefile.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian.debian.org still at 1.23.12
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: Get one way or the other with the db/lintian.index files and the files in pool and possibly parts of bin/genlist a lintian.log out of this framework :). If you can do this, I can probably quite easily get the lintian.log file quite easily into the html files on lintian.debian.org, but generating the lintian.log file is not really trivial. I may well be missing something, as that seemed fairly straightforward, so let me know what I didn't notice. consolidate-lintian and lintian.log in ~rra on merkel. You can fine the current format of lintian.log in /org/qa.debian.org/data/lintian.log , and $lintian/reporting/html_reports takes that file... and other information too. Maybe some totally new code to generate lintian reports would be better... one that's already generic enough to allow showing other type of results. It's a tradeoff between getting recent-lintian results publishable fastest, or doing it 'right' the first time around :). I'm interested in your thoughts on this. I've been meaning to take a look at the report generation anyway, given the couple of bugs that have been reported on it. I'll look it over and see if I get any brilliant ideas. One thing I would like to see is a way to get the info tags for a package, so in general it would probably be a good idea to provide a way to see tags only at a particular level. Eventually, I'd like to see lintian errors and possibly warnings integrated with todo items on the QA package summary, but that can happen later. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian.debian.org still at 1.23.12
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Wed, Apr 05, 2006 at 02:18:01PM -0700, Russ Allbery wrote: I may well be missing something, as that seemed fairly straightforward, so let me know what I didn't notice. consolidate-lintian and lintian.log in ~rra on merkel. Well, you missed the fact that the index file will list all packages, regardless of suite and arch. The current lintian.d.o interface simply isn't capable of showing that, so it should be limited. Ah, okay, that's easy enough to do. For right now, we should probably limit to i386 and source (although I see that genlist right now is restricted to source). Hm, suite is a more interesting and challenging problem. The most useful approach for the current lintian pages (which only show each package once) is probably to show unstable, but it looks like the suite isn't captured in the index file? Given that, my first inclination would be to only include the latest version of any given package, but maybe I'm missing something else. Down the road, I think generating a combined log file is the wrong approach; I think it would be better to generate the lintian report pages on the fly out of a database (of some sort; part of the database may be a collection of flat files containing the lintian output and the only database stuff might just be the package metadata). I think we want to index by at least the following: * Package * Suite * Maintainer * Architecture The most common views are going to be show all lintian warnings for the given source package and any binary packages it produces, looking only at i386 binary packages and the given suite and show all lintian warnings for any source or binary packages by the given maintainer in unstable, looking only at i386. The more advanced option would be to suppress other architectures only if the tags duplicated tags already seen for i386. We could toss this into a separate MySQL database, but actually, looking at this data, all of this would already be in the QA information used to generate the current pages. Is that information already stored in MySQL or PostgreSQL or the like? It would be great if it were, since then we could do the queries directly on it, and the only part left would be hunting down the actual log files containing the lintian messages, if any. I'm not entirely sure yet how this all is going to work together exactly, there's more things that needs such techinques to show only particular archs/suites/etc. And the html_reports thingy is still being a bitch at me, it requires some other permanent-lab internal data... I'll poke at it and see what sort of internal data it's looking for. Info tags are reported, I think the reporting might hide them indeed... oh well. Brilliant idea's appreciated :) Once we generate the reports dynamically, that will be easy to handle as another display option. Although I'm not sure about performance issues. Are dynamic web pages generally a bad idea? I have *no* idea what level of traffic we're talking about here. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian.debian.org still at 1.23.12
Russ Allbery [EMAIL PROTECTED] writes: Jeroen van Wolffelaar [EMAIL PROTECTED] writes: I'm not entirely sure yet how this all is going to work together exactly, there's more things that needs such techinques to show only particular archs/suites/etc. And the html_reports thingy is still being a bitch at me, it requires some other permanent-lab internal data... I'll poke at it and see what sort of internal data it's looking for. Ah, it needs the results of unpack/list-srcpkg, unpack/list-binpkg, and unpack/list-udebpkg. There isn't enough information in the index file in the new stuff to generate those files, so it looks like it has to be done by parsing the Sources.gz and Packages.gz files directly in the same way that genlist does. That will also let me figure out exactly which packages are in unstable, since we have to do that anyway. I'll look at adding that in. I think that's all of the lab output that lintian really needs. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362566: please add gambas interpreters to lintian
L Redrejo [EMAIL PROTECTED] writes: Package: lintian Severity: wishlist Gambas is a complete visual development environment for BASIC in linux. The stable version of gambas has gbx as its interpreter and it's already in Debian in the gambas-runtime package. The development version of gambas has gbx2 as its interpreter and will be uploaded to Debian in the short future. So, please, add gbx and gbx2 as interpreters to lintian. I see that /usr/bin/gbx is provided by gambas-runtime. What will be the package name that provides /usr/bin/gbx2? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New lintian checks for X.Org 7 migration
not be configured to install - files under the /usr/X11R6/ directory unless they use imake. The /usr/X11R6/ - directory hierarchy should be regarded as deprecated for all packages except - the X Window System itself. + files under the /usr/X11R6/ directory. Debian has switched to the modular + X tree which now uses regular FHS paths and all packages should follow. . - Programs that use GNU autoconf and automake are usually easily configured at - compile time to use /usr/ instead of /usr/X11R6/, and this should be done - whenever possible. -Ref: policy 11.8.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 + paths. Tag: config-file-reserved $file Type: error Index: testset/tags.manpages === --- testset/tags.manpages (revision 616) +++ testset/tags.manpages (working copy) @@ -14,6 +14,14 @@ E: manpages: manpage-not-compressed-with-gzip usr/share/man/man1/usr-bin-binary-alt.1.gz E: manpages: manpage-not-compressed-with-gzip usr/share/man/man1/usr-sbin-binary.1.gz E: manpages: manpage-not-compressed-with-max-compression usr/share/man/man6/usr-games-binary.6.gz +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/ +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/man/ +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/man/man1/ +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/man/man1/rstartd.1x.gz +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/man/man6/ +E: manpages: package-installs-file-to-usr-x11r6 usr/X11R6/man/man6/X11R6-binary.man +E: manpages: package-installs-file-to-usr-x11r6-bin usr/X11R6/bin/ +E: manpages: package-installs-file-to-usr-x11r6-bin usr/X11R6/bin/rstartd E: manpages: x11-games-should-be-in-usr-games usr/X11R6/man/man6/X11R6-binary.man W: manpages source: ancient-standards-version 3.2.1 W: manpages source: binary-nmu-debian-revision-in-source 4-0.0.1 @@ -32,11 +40,3 @@ W: manpages: manpage-has-bad-whatis-entry usr/share/man/man1/usr-sbin-binary.1.gz W: manpages: manpage-has-bad-whatis-entry usr/share/man/man6/usr-games-binary.6.gz W: manpages: manpage-has-errors-from-man usr/share/man/man1/test-latin1-chars.1p.gz 9: warning: can't find numbered character 228 -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/ -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/bin/ -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/bin/rstartd -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/man/ -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/man/man1/ -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/man/man1/rstartd.1x.gz -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/man/man6/ -W: manpages: packages-installs-file-to-usr-x11r6 usr/X11R6/man/man6/X11R6-binary.man Index: testset/tags.filenames === --- testset/tags.filenames (revision 616) +++ testset/tags.filenames (working copy) @@ -7,6 +7,9 @@ E: filenames: package-contains-ancient-file usr/lib/perl5/foo/ancient.pm 1975-01-01 E: filenames: package-installs-file-to-usr-something-x11 usr/bin/X11/ E: filenames: package-installs-file-to-usr-something-x11 usr/bin/X11/testxbin +E: filenames: package-installs-file-to-usr-x11r6 usr/X11R6/ +E: filenames: package-installs-file-to-usr-x11r6-bin usr/X11R6/bin/ +E: filenames: package-installs-file-to-usr-x11r6-bin usr/X11R6/bin/testxbin2 E: filenames: package-installs-packlist usr/lib/perl5/foo/.packlist E: filenames: postinst-does-not-call-updatemenus usr/share/menu/menu E: filenames: postrm-does-not-call-updatemenus usr/share/menu/menu @@ -63,9 +66,6 @@ W: filenames: package-contains-svn-control-dir usr/lib/perl5/.svn/ W: filenames: package-installs-nonbinary-perl-in-usr-lib-perl5 usr/lib/perl5/foo/ancient.pm W: filenames: package-installs-nonbinary-perl-in-usr-lib-perl5 usr/lib/perl5/foo/bar.pm -W: filenames: packages-installs-file-to-usr-x11r6 usr/X11R6/ -W: filenames: packages-installs-file-to-usr-x11r6 usr/X11R6/bin/ -W: filenames: packages-installs-file-to-usr-x11r6 usr/X11R6/bin/testxbin2 W: filenames: svn-commit-file-in-package files/svn-commit.tmp W: filenames: symlink-is-self-recursive usr/lib/filenames/symlink10wrong ../../.. W: filenames: symlink-is-self-recursive usr/lib/filenames/symlink5ok+warn .. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian checks for X.Org 7 migration
Russ Allbery [EMAIL PROTECTED] writes: If the package uses imake, it must build-depend on xutils-dev (= 1:1.0.2-1) for the correct paths. If it uses dh_installxfonts to handle X font installation, it must build-depend on debhelper (= 5.0.29). Ugh, sorry, all of those 1:1.0.2-1 mentions should be 1:1.0.2-2. I cut and pasted the wrong thing. Fixed in my version. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian checks for X.Org 7 migration
Daniel Stone [EMAIL PROTECTED] writes: On Sun, Apr 16, 2006 at 11:53:10AM -0700, Russ Allbery wrote: Tag: package-installs-file-to-usr-x11r6-bin Type: error Info: Debian has switched to the modular X tree which now uses the regular FHS paths, and all packages must follow. All packages installing binaries must install them into /usr/bin (or some other appropriate location) instead of /usr/X11R6/bin. . The x11-common package attempts to change /usr/X11R6/bin into a symlink to /usr/bin, so if this migration has already occurred, a package installing files into /usr/X11R6/bin may appear to install 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 (= 1:1.0.2-1) for the correct paths. Doing this was broken anyway, unless it was part of the core X Window System, which it wasn't. It used to be a warning that said you were only supposed to do this if the package used imake. (Policy still says that's allowed; we'll have to get policy changed once everything has settled down and then I can re-add the policy references to the lintian tests.) The tests look fine to me; thanks again for taking this on. Absolutely. I'll get them committed. We were about due for another lintian release anyway. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Time for a new release?
How do folks feel about a new lintian release? Since the previous release, 26 bugs have been fixed and there are 116 lines of changelog. I'd particularly like to get the new X11R7 tests just added today out there, since they should help with the transition (and there was one test that was wrong for the transition; xfonts-utils is not an xfonts package and does have to be depended upon). This release will catch a lot of problems that previously weren't caught, particularly missing debian/rules targets (binary-indep and binary-arch are very frequently missing from packages that only have one type of binary package or the other) and debhelper listed in Build-Depends-Indep (probably due to the previous lintian check) when it should be in Build-Depends. Both of those are errors and policy violations, but I expect at least a few complaints since they don't obviously break things. It will be nice to get the CDPATH fix out there, as that's bitten a few people. Anyway, please raise objections if you don't think we're ready for another release, and otherwise please test what's currently in Subversion and make sure it looks good. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time for a new release?
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Anyway, please raise objections if you don't think we're ready for another release, and otherwise please test what's currently in Subversion and make sure it looks good. I fear I don't have the time to do that, but I'm also in favor of doing a release. There's *no* reason to not release lintian early and often... I've personally done sufficient testing to feel reasonably confident, so how about this. I'm going to plan on uploading the next version of lintian on Friday, April 21st, unless there are any objections. If anyone wants me to hold off, speak up. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278290: Check does not work(?)
Torsten Marek [EMAIL PROTECTED] writes: no matter what I do, I always receive the error missing-dh_python-build-dependency. My build dependencies are the following: Build-Depends: debhelper(= 5.0.0), dpatch Build-Depends-Indep: python (= 2.3), python-qt3, python-qt-dev, sip4, qt3-dev-tools, python-kde3, python-kde3-dev My Perl foo is not good enough to create a patch, but somehow dh_python (instead of python) is treated as a package name that should be depended on. Indeed, the comment even said that it was going to be special-cased and then I didn't actually do that. I'm going to see about knocking off a few other bugs today and will upload a new version with this fixed by the end of the day. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364297: missing-dh_python-build-dependency does not check build-dep-indep
Julien Danjou [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.17 Severity: normal Hello dear lintian maintainers, It seems that missing-dh_python-build-dependency does not check build-dep-indep since svnmailer 1.0.8-4 has a build-depends-indep on python, but I get an error: E: svnmailer source: missing-dh_python-build-dependency Yup, my fault, I messed up that check. A new version will be uploaded with a fix by the end of the day. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364330: lintian: Please account for python-dev's dependency on python
Aaron M Ucko [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.17 Severity: normal Lintian's latest Python build-dependency checks are a bit too strict IMO -- in particular, they insist on direct build-dependencies on python, whereas I would argue that build-dependencies on python-dev should be sufficient. Could you please loosen the checks accordingly? Actually, they're buggy more than they're strict; I'm going to upload again later today to fix that. However, just to check, are you using dh_python? If so, that's where the check is coming from. dh_python actually does require python itself. However, I see that python-dev depends on python, so you get it through a transitive dependency. I'm not sure how safe it is to rely on that always being the case going forward, but maybe it should be -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364521: patch files are tagged as shell-script-fails-syntax-check
Matthias Klose [EMAIL PROTECTED] writes: Package: lintian E: gcc-4.1-source: shell-script-fails-syntax-check ./usr/src/gcc-4.1/patches/ppc64-ada.dpatch E: gcc-4.1-source: shell-script-fails-syntax-check ./usr/src/gcc-4.1/patches/gccbug.dpatch not sure, if I should mark them with an overrides file or if that could be fixed in lintian Ah, I see, bash -n doesn't stop checking at exit 0. Which makes sense; the exit could be conditional and the flow control understanding required to establish that it's not is probably hard to do. I think the right solution may be for lintian to ignore shell scripts with a suffix of .dpatch in /usr/src. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365041: lintian: wrong build-depends-without-arch-dep quilt
Marc Dequènes (Duck) [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.18 With CDBS, or any packaging system, patch management may be used and the selected patch tool is necessary in the clean rule to unpatch. Then quilt (and dpatch) should not trigger this error. lintian already detects this case when either the quilt or dpatch makefile fragments are included or when they're invoked explicitly in the clean rule or a dependency. I just need to know the CDBS inclusion that triggers the same thing and I'll fix this. I want it to actually look rather than just bailing if CDBS is used, since I think it can do a better job there. Looking over CDBS, my guess is that the trigger is: include /usr/share/cdbs/1/rules/patchsys-quilt.mk for quilt and: include /usr/share/cdbs/1/rules/dpatch.mk for dpatch. Does that look right to you? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#365503: xfonts-encodings is not a font package
Drew Parsons [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.18 Severity: normal If a package (xprint-common in my case) Depends: xfonts-encodings, then lintian returns the error package-depends-on-an-x-font-package depends: xfonts-encodings citing Policy 11.8.5 if a binary package needs a given font then it must Recommends: it, not Depends:. But xfonts-encodings is not a font package (it's a font infrastructure package), so I don't think 11.8.5 applies to it. *grumble*. We had a good heuristic for this, but several of the new X.Org packages don't follow it. I'll add this to the exception list (xfonts-utils we already ran into). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365466: lintian: wrong build-depends-without-arch-dep patchutils
Marc Dequènes (Duck) [EMAIL PROTECTED] writes: I think having cdbs with import of any of the 3 patch system should be a sufficient condition to allow patchutils. if you think it is not, please reassign this bug to cdbs, so as to request the necessary modifications of both the rules and the Build-dependency generation helper. Oh, I agree that it should allow the dependency. The reason why it's trickier is that right now that part of lintian doesn't distinguish between allowed dependencies and required dependencies, so if I just add this as another case, everyone using any of those patch systems would *have* to Build-Depend on patchutils to avoid warnings. I don't think that's right; people may not care about that functionality and CDBS does fall back on other techniques. It's not a big deal; I just need to add another case in the code. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Time for another upload
Given that we've gotten a bug filed for the latest policy update, I think it's about time for another upload. I've accumulated a fair number of bug fixes in Subversion beyond just keeping up with new incoming bugs, so I feel like we're making forward progress. I'm therefore planning on uploading 1.23.20 on Monday unless someone yells. The new debconf template checks following the Developer's Reference recommendations are the most likely source of bugs and false positive complaints in this release. They look like they're going to result in quite a few new lintian warnings, but they seem reasonable and have already been vetted in the Developer's Reference and we can adjust if any of them are too unpopular. The doc-base checks will probably also find some problems, but those I have a higher confidence will all be bugs. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366481: lintian: Can't locate common_data.pm in @INC
Nelson A de Oliveira [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.20 Severity: important Hi! Today I have downloaded lintian 1.23.20 from incoming and installed it with dpkg -i. Trying to test it with some packages, I've got: $ lintian qsf_1.1.7-1_i386.deb Can't locate common_data.pm in @INC (@INC contains: /usr/share/lintian/lib /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/share/lintian/checks/menus line 25. BEGIN failed--compilation aborted at /usr/share/lintian/checks/menus line 25. Compilation failed in require at /usr/share/lintian/lib/Checker.pm line 63. Ack, thank you very much for the fast report. I've uploaded 1.23.21 with the fix. I added common_data.pm to the menus checks to pick up some information and forgot to add the use lib line that is also required in order to load it. I didn't notice that in any of my testing since most of my checks I used --root with, and the ones that I did without --root were only on *.changes files, which for some reason works. Hopefully I'll get it into the archive before the next archive push so no one in unstable will be affected. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366769: lintian: [check/fields] false positive when building against a specific python version
Vincent Danjean [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: normal One of my packages (mercurial) needs python2.4. So I specifically build-depends on python2.4-dev. Since a few days, lintian complains about a missing build dependency: E: mercurial source: missing-build-dependency python | python-dev | python-all-dev It seems to ignore my depend on python2.4-dev. However, my package perfectly builds in a pbuilder environment (without any depends requested by lintian). So it seems that lintian has too strict tests with respect to python. Are you using dh_python? dh_python specifically requires that /usr/bin/python exist. As near as I could determine, installing the versioned packages (python2.4, python2.4-dev) does not create /usr/bin/python, only /usr/bin/python2.4. Hence the warning. dh_python doesn't look for python2.4 or python2.3; it just bails out with an error if /usr/bin/python doesn't exist. Are you sure that dh_python is working in your chroot build of the package? And if so, could something else be pulling in python for you via a transitive dependency? If you're not using dh_python, something else may be going on; let me know if that's the case. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367324: lintian: reports amd64 as non-standard arch (infomational message)
Lior Kaplan [EMAIL PROTECTED] writes:
Package: lintian
Version: 1.23.21
Severity: normal
--- /usr/share/lintian/checks/common_data.pm.orig 2006-05-15
03:05:45.0 +
+++ /usr/share/lintian/checks/common_data.pm2006-05-15 03:08:32.0
+
@@ -15,7 +15,7 @@
# simple defines for commonly needed data
%known_archs = map { $_ = 1 }
-('alpha', 'arm', 'hppa', 'hurd-i386', 'i386', 'ia64', 'mips', 'mipsel',
+('alpha', 'amd64', 'arm', 'hppa', 'hurd-i386', 'i386', 'ia64', 'mips',
'mipsel',
'm68k', 'powerpc', 's390', 'sparc', 'any', 'all');
The source for this data is dpkg, which doesn't yet list amd64 in
/usr/share/dpkg/archtable. I'd been sort of holding off until dpkg
changed. But that's probably pointless... I think amd64 is about as
official as it gets at this point.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367466: lintian: enhancement, check for missing menu files
Matt Taggart [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: wishlist I have an idea for a lintian enhancement. There are packages that provide GUI programs (gtk,qt,etc.) that do not provide a menu file for those programs, ideally they would all provide menu files. Here is a patch that adds a test to the binaries check. It checks each executable binary to see if it uses libX11 and if any do and the package doesn't have a menu file it issues a warning. I have tested it on I'm worried about the number of false positives here, from packages like gksu that might link with X libraries but shouldn't have menu entries for themselves. There may be quite a few helper programs like that that link with X but aren't applications in the menu sense. (There are also a lot of false negatives, of course, including binaries that link with a toolkit rather than with the X libraries directly, but that doesn't necessarily rule it out.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368206: lintian: Should not warn for writing style in untranslatable templates
Thomas Huriaux [EMAIL PROTECTED] writes: There is no way to find in a binary package if the strings are marked as translatable. Oh, hm, yes. I hadn't realized that, but that makes sense. Using the source package is also a bad idea, as these templates may be modified at build time. Yeah, and with all the weird build systems out there (yada comes to mind), trying to find the templates in the source package can be quite hard. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367466: lintian: enhancement, check for missing menu files
Matt Taggart [EMAIL PROTECTED] writes: OK, I'd like to try to fix the patch to deal with any false positives. Does someone run lintian on the whole archive that could try with this patch and give me a list of packages that report the problem? I'm not sure that anyone is currently doing this. It unfortunately takes a very, very long time to do. I've been meaning to set up a test environment where I can run that sort of controlled test, but realistically I'm not going to have time before late this summer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368792: script-not-executable false positives
Peter Eisentraut [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: normal The check script-not-executable apparently thinks that everything that starts with #! should be executable, which is far from true. A lot of, say, python or php scripts are installed somewhere under /usr/share and carry that #! for documentation value or just for no reason at all, but it's there. Perhaps that check should be restricted to scripts that are installed in program directories such as /usr/bin. This has been discussed before and the general consensus that I recall from previous discussions is that such scripts should either be marked executable or have that line removed if they really can't be executed independently. Limiting the check to /usr/bin can miss cases where the non-executability (due to a buggy install script, for instance) breaks the package because it can't execute its helper scripts, so I'm not horribly enthused about changing the test itself. It's actually more likely for packages to have problems with helper scripts in /usr/share than with the regular binaries in /usr/bin. I'm certainly happy for other lintian maintainers to disagree on this, though. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: B-Depends and B-Depends-Indep with python-dev and cdbs
Jan Lübbe [EMAIL PROTECTED] writes: Hi! Lintian shows this warning on my package: W: python-pysnmp2 source: build-depends-without-arch-dep python-dev N: N: The control file lists the given package in Build-Depends, but no N: architecture-dependent packages are built. If all the packages built N: are architecture-independent, the only packages that should be listed N: in Build-Depends are those required to run the clean target (such as N: debhelper if you use dh_clean). Other build dependencies should be N: listed in Build-Depends-Indep instead. N: N: Refer to Policy Manual, section 7.6 for details. I have: Build-Depends: cdbs (= 0.4.23-1.1), debhelper (= 4.2.0), python-dev The package is build with cdbs and uses the python distutils. Cdbs calls 'python setup.py clean -a', which of course requires python-dev. Should i override this warning or is there a better solution? The way that lintian tries to detect this case is by looking for a line like: include /usr/share/cdbs/1/class/python-distutils.mk in your debian/rules file. If there's some other way to tell cdbs to use Python, let me know and I'll definitely add it to lintian. We're still chasing down several more edge cases with these rules, as unfortunately it's a bit complex to detect programmatically what is called during a clean rule and what isn't. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: B-Depends and B-Depends-Indep with python-dev and cdbs
Jan Lübbe [EMAIL PROTECTED] writes: On Fri, 2006-06-02 at 13:55 -0700, Russ Allbery wrote: The way that lintian tries to detect this case is by looking for a line like: include /usr/share/cdbs/1/class/python-distutils.mk in your debian/rules file. If there's some other way to tell cdbs to use Python, let me know and I'll definitely add it to lintian. We're still chasing down several more edge cases with these rules, as unfortunately it's a bit complex to detect programmatically what is called during a clean rule and what isn't. That line is in debian/rules, so i'm not sure what the cause is. See http://svn.debian.org/wsvn/python-modules/packages/python-pysnmp4/trunk/debian/rules?op=filerev=0sc=0 Oh, wait, I see what the problem is. That detects that a Python dependency is needed, but doesn't think it's needed for debian/rules clean. My bad. Will be fixed in the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#370720: virtual-package-depends-without-real-package-depends is bodus
martin f krafft [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: normal W: mdadm: virtual-package-depends-without-real-package-depends recommends: mail-transport-agent N: N: The package declares a depends on a virtual package without listing a N: real package as an alternative first. N: N: A real package should be listed in the first part of the | dependency N: in order for the package to be installable by package management N: programs that can't or won't guess which alternative to select by N: default. In particular, it helps build daemons rebuild the package N: without manual overrides. N: N: Refer to Policy Manual, section 7.4 for details. This makes no sense. Build daemons are only concerned about build-depends, and there isn't one package management programme in Debian that can't pick an alternative. Please at least don't show this warning for recommends/suggests. If package A Build-Depends on package B which in turn then Depends on virtual package C, I can see two possibilities: either the package system will want to prompt someone for what package to install, which won't work because it's non-interactive, or the installed package to satisfy the dependency on virtual package C will be chosen essentially at random. The latter leaves open the possibility that a different choice will be made next time, meaning that we no longer have a consistent and reproducible build environment. That strikes me as bad, although I'm not sure it's bad enough to warrant the lintian warning. I'd at least want to see some more discussion of that first. I think I agree with you on recommends/suggests. Unless any other lintian maintainer has an objection, I'll exempt recommends/suggests from this check. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372190: build-depends-without-arch-dep with cdbs/ant packages
Peter Eisentraut [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: normal When a package using cdbs and ant runs its clean rule, it looks like this: Is there a particular CDBS file that is included for such packages that lintian could trigger off of and grant a general exemption? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365041: lintian: wrong build-depends-without-arch-dep quilt again
clone 365041 -1 retitle -1 direct invocation of quilt in debian/rules clean not recognized close 365041 Sam Hocevar [EMAIL PROTECTED] writes: reopen 365041 thanks Hi! I have the following rule in my clean target: QUILT_PATCHES=debian/patches quilt pop -a -R || test $$? = 2 Yet lintian still complains about build-depends-without-arch-dep quilt. Yes, because currently lintian doesn't look for direct invocations of quilt, only for use of the CDBS or quilt makefile fragments. This doesn't have anything to do with the CDBS problem in the bug that you reopened. Please file new bug reports for new problems so that we can better track in debian/changelog what's been fixed in each release. Thanks! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365041: lintian: wrong build-depends-without-arch-dep quilt
Marcus Better [EMAIL PROTECTED] writes: Russ Allbery wrote: I don't. What version of lintian are you using? lintian is 1.23.21. And do you have a dependency on the right version of quilt? Here's debian/control: Source: ixp400-accesslib Section: misc Priority: optional Maintainer: Marcus Better [EMAIL PROTECTED] Build-Depends: debhelper (= 5.0.0), quilt (= 0.40) Build-Depends-Indep: dh-kpatches, bzip2 Standards-Version: 3.7.2 Oh, bleh, I see what's wrong. Fixing this in Subversion. Thank you! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344269: etch release policy: scripts must set appropriate #! line?
Frank Küster [EMAIL PROTECTED] writes:
Dear release team,
we have not heard from you on this. Could you please clarify your
policy decision? This was the central question:
Release Managers, do you think that (upstream-provided) scripts with a
Perl magic header like
,
| eval '(exit $?0)' eval 'exec perl -S $0 ${1+$@}' eval 'exec perl -S
$0 $argv:q'
| if 0;
`
are inacceptable? Fullquote follows,
I thought Steve followed up and said that yes, they're unacceptable,
because that script magic relies on the script being run by a shell
(something I hadn't realized until he pointed it out). If you try to run
a binary that starts with the above and no #! line via, say, execv inside
a C program, it will fail. It only works from the command line because
the shell falls back on trying to interpret binaries with no valid magic
as shell scripts.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Uploads
Raphael Hertzog [EMAIL PROTECTED] writes: (moving to lintian-maint) On Fri, 23 Jun 2006, Russ Allbery wrote: Raphael Hertzog [EMAIL PROTECTED] writes: I tend to think that you're doing too much checks here. Having too much in Build-Depends is not *that* bad. You'd better check only for the contrary ie missing Build-Depends because they are used in the clean rule... well IMO of course. This would be a good thing to send to lintian-maint rather than just to me. I didn't add the check in the first place; I just tried to fix all of the false positives in a check that was already in lintian before I started working on it. I agree with you that it's not completely clear it's worth it, although at this point there aren't many false positives left. I have nothing to add, just wanted to share my initial comment with the other maintainers as suggested by Russ. What would the other lintian maintainers think about downgrading the build-depends-without-arch-dep tag to info from warning? We are getting a *lot* of false positives with it, and while I'm quashing them as I see them, this is a style thing more than it's really a policy requirement. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Time for 1.23.22
Since the tar fix requires a change to lintian, I think it's time for another upload. If anyone has objections, voice them now, or I'll make an upload tomorrow from what's in Subversion. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time for 1.23.22
Jeroen van Wolffelaar [EMAIL PROTECTED] writes: On Tue, Jun 27, 2006 at 12:54:01PM +0200, Jeroen van Wolffelaar wrote: On Mon, Jun 26, 2006 at 05:46:33PM -0700, Russ Allbery wrote: Since the tar fix requires a change to lintian, I think it's time for another upload. If anyone has objections, voice them now, or I'll make an upload tomorrow from what's in Subversion. I don't like the tar change (I mean the change in tar, not necessarily the change in lintian). The current solution will make lintian unusable with older tar versions, which is a step futher than the perl library backports needed so far. Eh, I later read on -devel that this is actually not the case -- I tested this in testing and the testlab totally failed, but I might have misinterpreted this failure -- indeed, it turned out that I simply didn't have cdbs installed. Yeah, I was worried about that too but then went back and checked changelogs and became less worried. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344269: etch release policy: scripts must set appropriate #! line?
Frank Küster [EMAIL PROTECTED] writes: reopen 344269 found 344269 1.23.21 retitle 344269 Please reintroduce executable-not-elf-or-script with perl magic header and change it to an error thanks Did you check to be sure this was really in 1.23.21? After Steve's response, I already reintroduced this check in 1.23.19, so if this check isn't in the current lintian there's some sort of regression that I don't understand. * checks/scripts: + [RA] Debian etch release policy explicitly forbids scripts without #! magic and they rely on being run from a shell. Revert the change that permitted the Perl magic without a #! line. Thanks to Piotr Engelking and Steve Langasek for pointing this out. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#375638: lintian: deb-created-with-broken-tar: typos and tar version clarification
Thijs Kinkhorst [EMAIL PROTECTED] writes: 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. It's not really a bug in tar, either, so the description and the tag aren't very accurate. It's a bug in dpkg's internal tar implementation when encountering filenames that are exactly 100 characters long (shorter or longer is fine), and that bug has since been fixed in dpkg. In the meantime, tar was also modified to avoid that case, but it was following the standards before. We need to figure out if dpkg was fixed before the sarge release; if so, this tag should be dropped from lintian entirely. The current version of tar in unstable now generates these sorts of archives again, so if tar is going to be changed again, we'll have to list the current version as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375764: lintian: man page doesn't know about option '-t'
Matthias Julius [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.21 Severity: minor When using the option '-I' lintian says: N: Informational is deprecated, use -t E,W,I But, the lintian man page does not mention this option. Hm... I use lintian -I all the time and haven't encountered this message. And: windlord:~/dvl/debian/lintian grep -r 'Informational is deprecated' * windlord:~/dvl/debian/lintian lintian -I ~/tmp/test.deb windlord:~/dvl/debian/lintian lintian -i -I ~/tmp/test.deb So I can't reproduce this -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian and boot dependency violations.
Carlos Villegas [EMAIL PROTECTED] writes: Hi, i'm working on improving the boot system as part of the google summer of code (1) with Petter Reinholdtsen as my mentor, and we are working on a script that would check init scripts correct order. As a result, problems with the boot process would be reduced and a faster parallel execution could be used as a bonus. Currently, there are some init scripts with a the wrong order like alsa-utils and udev which are placed after programs they are supposed to require: sysklogd and mountvirtfs respectively. I've placed the bug reports for alsa-utils and udev but if lintian would report when dependency information is missing, it would be easier to use a script adjust the order of the init scripts to ensure that these are met for each system (as dependency information would be available). With the advantage of making parallel execution possible. It sounds like a possibly good idea, except that I have no idea what dependency information you're talking about and Policy doesn't give me a clue. I do see some fields in the init.d skeleton file, but they're very opaque to me, I thought they were only there for compatibility with Red Hat and nothing in Debian used them, and I would have no idea how to fill them out. Is there some sort of existing policy document that explains all of this, and to which we could code lintian checks? If not, I think developing such a document would be the first step. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376920: lintian: missing-build-dependency cdbs even though depends on dh-make-php
Charles Fry [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: normal I receive an error from lintian, complaining that my package is missing a build-dependency on cdbs, even though it depends on dh-make-php which depends on cdbs. It's not clear to me that this is a bug in lintian. I don't see anything in the documentation of dh-make-php that guarantees that it will always depend on cdbs in the future, so if your package is directly using cdbs features, I think you should add an explicit cdbs dependency. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376920: lintian: missing-build-dependency cdbs even though depends on dh-make-php
Charles Fry [EMAIL PROTECTED] writes: In my opinion, lintian doesn't need to predict the future. As long as the requisite dependency is met, the test should pass. If this changes in the future, the test should fail. As for dh-make-php, as one of the maintainers I can vouch that the only reason to depend on dh-make-php at build time is to use the cdbs module pear.mk. But you're also using other cdbs modules not supplied directly by dh-make-php, correct? Certainly, the template generated by dh-make-php does so. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376920: lintian: missing-build-dependency cdbs even though depends on dh-make-php
Charles Fry [EMAIL PROTECTED] writes: As for dh-make-php, as one of the maintainers I can vouch that the only reason to depend on dh-make-php at build time is to use the cdbs module pear.mk. But you're also using other cdbs modules not supplied directly by dh-make-php, correct? Certainly, the template generated by dh-make-php does so. True enough. I can see various philosophies about this, and I'm happy to be persuaded if what I'm saying doesn't make sense, but the general rule of thumb I've been using is that packages shouldn't rely on transitive dependencies to pick up packages that they use directly. In other words, if a package calls patch directly in debian/rules, it should Build-Depend on patch, even if it also Build-Depends on a patch management system like quilt that in turn depends on patch. If a package links directly with some library, it should depend on the appropriate -dev package, even if another library it also uses pulls in that -dev package. There are some (maybe even many) cases where such reliance on transitive dependencies would be safe, but I think it's an area that benefits from a rule of thumb, and it makes it a lot easier to write things like lintian without a surfeit of special cases. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377392: Bug#377382: lintian: Please add a check for macros in manpages
tags 377382 -patch retitle 377382 [manpages] check for undefined macros thanks Checking the validity with the man command does not report errors about macros. The workaround is to use groff -wmac. The result of a wrong macro is often a missing line in the displayed manpage. For example, shmget.2 (manpages-dev) contains the undefined macro .Br proc (5). instead of .BR proc (5). If you have a look at the displayed manpage, you will see that proc(5). is missing at the end of the following sentence: See also the discussion of the file /proc/sys/vm/overcommit_memory in The attached patch should allow lintian to warn about these problems. Unfortunately, there are reasons why we're using man -l other than that it knows what formatter to run. It also processes .so inclusions of compressed files, and contrary to the comment, I'm afraid those *aren't* checked elsewhere. Only the simple ones are. Basically, this patch would revert the fix for #349614. It's also not okay to run system commands from inside lintian with simple backticks; you have to clear the environment first, or weird things can happen (users with CDPATH set in the environment are a common problem). I poked at this patch for about an hour, and I can't find a way of fixing those issues that I'm very happy with. I suppose we could run all man pages through both man -l and then through groff just to check for macros, but I'm also worried that undefined macros are sometimes used intentionally for optional parsing (the bash man pages, for instance) and we're leaving people without a recourse other than an override. Although maybe that's not too bad I'm going to remove the patch tag from this one since I don't think it should be applied as-is, but if you come up with an improved patch, please let us know. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: package: lintian version: 1.23.22 Hi, the new version of policy mandates FHS 2.3, which requires /srv, so this is clearly no error :-) By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 02:49, you wrote: By my reading of FHS 2.3, no Debian-supplied package should be installing files into /srv, since /srv is reserved for the local administrator for local data. The error message may not be accurate, but it looks to me like this still should be an error. Am I missing something? I don't think you are correct: In http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM the last sentence about /srv says: --begin quote - Distributions must take care not to remove locally placed files in these directories without administrator permission. [20] [20] This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator. --end quote - So, as I read it, /srv is clearly designed for files from the distribution and locally added ones. How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 17:35, you wrote: How can that be reconciled with: The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. I don't see any way that shipping files under /srv in a Debian package would be consistent with the second-to-last sentence above. I do. But I think this is getting out of scope of this bug :) I don't; I think it's exactly the point. apache might ship with DocumentRoot in /srv/www - but apache must also work, if you modify this. You might have many DocumentRoots, in /srv/webserver/foo and in /srv/webserver/foo2... It says no program should rely on a specific subdirectory structure of /srv, not no program should rely on a specific directory in /srv - especially if you define this directory in the programms configuration. Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. If the local administrator decides they want to organize /srv differently, your files get in the way. If they delete them or move them, every time the package is upgraded, they're re-installed. To me, that seems to break the point that the above paragraph is driving at. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. Maybe we should take this to debian-policy and see what other folks think? I could be wrong and I'm happy to change lintian accordingly if the consensus is that I'm wrong. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379176: E: foo: non-standard-toplevel-dir srv/ is policy not an error
Holger Levsen [EMAIL PROTECTED] writes: On Saturday 22 July 2006 18:34, you wrote: Yes, and if you ship files in /srv, then your package is creating and insisting upon a particular structure in /srv. Even if the binaries in the package don't insist, the *package* is insisting. Yup. That's a structure my package created. Obviously I can depend on that. And the FHS says that you're not allowed to do that. So... lintian is correct, I think. Certainly, I can see shipping configuration that points to /srv for local data by default, and even a postinst that creates an initial structure in /srv for the package if this is the first install, but putting the files directly in the package seems to me to be forcing more structure than is allowed here. So you agree that the lintian error is wrong :) None of those things would trigger a lintian error. :) Maybe we should take this to debian-policy and see what other folks think? Sure. Go ahead. And thanks for caring! Okay, will do. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379749: trailing spaces not handled correctly in doc-base checks
Bas Zoetekouw [EMAIL PROTECTED] writes: Tailing spaces in doc-base files are not matches correctly in /usr/share/lintian/checks/menus I noticed this, because freesci-doc started failing lintian checks with this warning: W: freesci-doc: doc-base-file-unknown-format freesci-doc:15 text even though the doc-base file in the apckages looked fine. Upon debugging, it turned out the Format field in freesci-doc's doc-base file had trailing spaces, which lintian included in the format, causing it to try and match textto the known formats. Thanks! Applied. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how can I add custom lintian checks?
Eric Cooper [EMAIL PROTECTED] writes: I'm interested in adding some additional lintian checks (in this case, to verify conformance with the OCaml packaging policy). I was surprised to not find any packages providing policy plugins for Perl, Java, Emacs, etc., other than what's provided by lintian itself. One of the goals of lintian is to always provide the same results no matter where it's run from. Because of that, we've avoided having checks that aren't integrated in with lintian. Is there any reason not to just include such checks in lintian proper? They sound like a good idea to me. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380286: bogus missing-dh_python-build-dependency error with arch-specific build-deps
Rene Engelhard [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: normal Hi, $ lintian -i openoffice.org_2.0.3-4.dsc E: openoffice.org source: missing-dh_python-build-dependency python | python-dev | python-all-dev N: N: The package runs dh_python in debian/rules but doesn't build-depend on N: python or python-dev. dh_python requires /usr/bin/python to run, so N: packages using dh_python must build-depend on python (or python-dev or N: python-all-dev, which in turn depend on python), even if they don't N: otherwise need Python to build. N: N: Refer to the dh_python(1) manual page for details. wrong, because: Build-Depends: [...] python-central (= 0.4.10) [i386 powerpc sparc], debhelper (= 5.0.37.1), python (= 2.3.5-7) [i386 powerpc sparc], python-dev [i386 powerpc sparc] [...] As wee see, both python and python-dev is there. (and dh_python is only ran on i386, powerpc, sparc because the python package is only built there - but lintian of course cannot know it). But it imho should omit the warning because it's specified This is difficult to fix, since lintian is (correctly) realizing that the dependencies don't guarantee that those packages are installed. To fix this, we probably need to add a dependency checking function that ignores architecture strings. Ugh. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368206: lintian: Should not warn for writing style in untranslatable templates
Thijs Kinkhorst [EMAIL PROTECTED] writes: 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. Only if you mark it translatable. So don't do that. (In other words, omit the _ in front of Description.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381800: lintian: [checks/scripts] unjustified possible-bashism-in-maintainer-script
Alexander L Belikoff [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: normal Currently, lintian reports the shell construct 'if [[ ... ]]' as bashism. I am not sure this is correct, since all POSIX 1003.2 resources available to me declare '[[' and ']]' a standard conditional expression check in POSIX sh (don't confuse with older Bourne sh). Nope. [[ and ]] indicate built-in test evaluation, which is not a required feature of a POSIX shell. See: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html and observe that [[ and ]] are mentioned only in the following text: The following words may be recognized as reserved words on some implementations (when none of the characters are quoted), causing unspecified results: [[ ]] function select So the behavior of [[ and ]] is unspecified in a pure POSIX shell. If you want to use [[ or ]], you need to use #!/bin/bash or some equivalent. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382477: too-long-extended-description-in-templates: rather fix the tool than condense a description
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. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383203: lintian has a hard coded path prefix for the --dist option
vaqflabuopac [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.8 Severity: important lintian has a hard coded path prefix for the --dist option It doesn't, really, but the documentation isn't particularly clear. (It does have a hard-coded path component, but that would have worked fine for your example with the right options.) lintian --allow-root --show-overrides -viI --dist /var/local/packages/dists/custom/main You actually wanted: lintian --allow-root --show-overrides -viI \ --archivedir /var/local/packages --dist custom --section main I'll update the man page to be clearer about how lintian constructs the path to the package repository. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378088: new control file: clilibs
Hi, currently lintian throws an error about the clilibs control file. This control file is used in almost all CLI packages and has exactly the same purpose as the shlibs control file but for CLI libraries. Please add this to the list of known control files. Did this replace netlibs, or is netlibs still also of interest? I seem to recall that CLI and .NET are two different ways of talking about the same general set of technology. There was a previous bug filed about netlibs (Bug#255090) was that this should get into Policy first and then into lintian. I'm not sure if we need to be that strict, but I do want to see a real policy and specification. This: For more information on that file look here[1]. Bye [1]:http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-clilibs-control-file is a good start, but contains little of use in actually verifying the contents of the control file. At least a syntax specification would seem to be in order here. Is the intention for cli-policy to eventually become a subpolicy of the main Debian Policy manual? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382327: Please don't consider UNRELEASED an invalid distro
martin f krafft [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: wishlist E: mdadm_2.5.3-1~unreleased.3_i386.changes: bad-distribution-in-changes-file UNRELEASED I think it would be better not to flag this as an error. UNRELEASED is a commonly used name in changelogs during testing and it's refused by dak anyhow. If lintian reports an error, it's impossible to get error-free lintian runs during testing, which may lead maintainers to ignore lintian altogether (or miss other things in skim mode). I'm not completely sure about this one, since it *isn't* a valid distribution (that is, in fact, the entire point of using it). dak automatically rejecting it is a persuasive argument, though, and I suppose most other archive maintenance tools would do the same. That means I have a hard time seeing what damage could be caused by lintian recognizing it, other than maybe a wasted upload. I have a sneaking suspicion that if we do recognize it, we'll immediately get a request from someone to stop recognizing it since they were using lintian to remind themselves to change the distribution before uploading. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322657: [external] check bugs closed in changelog against BTS
tags 322657 wontfix thanks One very useful feature for lintian would be if it could check the bugs that are changed in the changelog against the bug tracking system to make sure that they are correct, e.g. belong to the package, are open, etc. Obviously, this wouldn't be a default check, since it uses the network, which you can't assume is available. However, it would be great as an optional check. I agree that it would be great to have a tool that does this, but it doesn't fit the model and goals of lintian. lintian is intended to be an entirely self-contained (except for its dependencies) package checker that doesn't depend on external data sources. There are, however, a bunch of good ideas in the lintian BTS for checks that a program without that constraint could make, so I'm tagging this wontfix rather than closing it so that someone else can look at those reports for inspiration. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Time for another lintian upload
As always, I didn't get everything in from the BTS that should be straightforward, but at least the Python checks are in and this should be a good chunk of stuff for a new release. Unless there are any objections, I'm going to upload what's in Subversion on Monday. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383958: lintian: python-script-but-no-python-dep error with python-support
Cameron Dale [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.22 Severity: wishlist Lintian generates python-script-but-no-python-dep errors for binary packages depending on python-support (which depends on python). These dependencies are sufficient and are generated automatically by the dh_pysupport debhelper script. I asked on debian-python and they said this was a bug in lintian and not in python-support: http://lists.debian.org/debian-python/2006/08/msg00098.html I don't think I agree with this. python-support is a package that, at least according to its long description, says that it provides a script that byte-compiles Python modules. Nothing in the description of the package says that it provides a Python interpreter. It happens to do so *now* because of its dependencies, but suppose there were some reason down the road why it might depend on some specific version of Python that didn't provide the /usr/bin/python interpreter or otherwise changes its functionality in some way. Please don't rely on transitive dependencies. It's just a lurking bug waiting to happen. Your package contains a Python script which requires a Python interpreter. It should therefore depend on the package that provides the Python interpreter. Unless python-support is defined to provide a Python interpreter, it's not the correct package to depend on for that purpose. In general, for every interface, system service, or binary that your package uses, you should depend directly on the package that provides that interface, system service, or binary unless that package is essential, and not assume that some other dependency will provide it for you. Time and again, transitions in Debian have proven that such assumptions break over time and suddenly make packages RC-buggy. Yes, sometimes it's very unlikely that such a transition will happen, but I think it's better as a general rule to be sure. If it's really the intention that python-support will always provide a Python interpreter, that should be added to its long description so that there's documentation that this is an invariant and a promise that won't be changed later. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378088: new control file: clilibs
Sebastian Dröge [EMAIL PROTECTED] writes: On Fr, 2006-08-18 at 18:11 -0700, Russ Allbery wrote: Did this replace netlibs, or is netlibs still also of interest? I seem to recall that CLI and .NET are two different ways of talking about the same general set of technology. Yes, it replaces netlibs. netlibs is not used by any current package anymore and clilibs was chosen because it describes the technology used better. Okay, thanks, I've closed the other bug. is a good start, but contains little of use in actually verifying the contents of the control file. At least a syntax specification would seem to be in order here. Ok, I'll add it there next week. So let's leave this bug open until the cli policy became part of the policy, ok? :) Or at least until there's a specification for the clilibs file in the CLI policy, which would probably be enough. Thanks! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#382327: Please don't consider UNRELEASED an invalid distro
martin f krafft [EMAIL PROTECTED] writes: also sprach Russ Allbery [EMAIL PROTECTED] [2006.08.19.0549 +0100]: I have a sneaking suspicion that if we do recognize it, we'll immediately get a request from someone to stop recognizing it since they were using lintian to remind themselves to change the distribution before uploading. Makes me think we should have dput/dupload check. That sounds like a good idea to me. Should I clone this bug against those packages? I'd rather see them pick up that check before lintian drops its. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383958: lintian: python-script-but-no-python-dep error with python-support
Pierre Habouzit [EMAIL PROTECTED] writes: Le lun 21 août 2006 02:30, Russ Allbery a écrit : If it's really the intention that python-support will always provide a Python interpreter, that should be added to its long description so that there's documentation that this is an invariant and a promise that won't be changed later. python-support is written in python (same is true for python-central) and will *always* depend upon 'python' Please see the rest of the message that I just wrote. Your response doesn't address my concerns. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
