Debian Bug report logs - #626476
lintian: reduce dpkg-dev to Suggests

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: submit@bugs.debian.org

Subject: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 10:45:49 +0100

Package: lintian
Version: 2.5.0~rc3
Severity: wishlist
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric

We're shipping lintian on Ubuntu CD images as a Recommends of aptdaemon,
in order to do some basic sanity checks on third-party binary packages.
Unfortunately this pulls in dpkg-dev and its dependencies, which are
rather heavyweight.  Some analysis shows that the only thing that we
need dpkg-dev for is to unpack source packages, so it's possible to
check binary packages without dpkg-dev.

The attached patch checks whether dpkg-source is available and produces
a better error message; it then drops dpkg-dev to a Suggests so that we
don't have to ship it.  I don't think this should particularly
negatively affect anyone - if you're building packages, you have
dpkg-dev installed anyway, and probably not solely by means of
installing lintian - but I thought I'd file a bug about it rather than
just committing it so that we could discuss it in case anyone had any
objections.

diff --git a/collection/unpacked b/collection/unpacked
index 1cceb5a..7688711 100755
--- a/collection/unpacked
+++ b/collection/unpacked
@@ -24,7 +24,7 @@ use strict;
 use warnings;
 
 use lib "$ENV{'LINTIAN_ROOT'}/lib";
-use Lintian::Command qw(spawn);
+use Lintian::Command qw(spawn on_path);
 use Util;
 
 ($#ARGV == 1) or fail('syntax: unpacked <package> <type>');
@@ -46,6 +46,10 @@ if ($type =~ m/^remove-/) {
 }
 
 if ($type eq 'source') {
+    unless (on_path('dpkg-source')) {
+	fail('dpkg-source missing - is the dpkg-dev package installed?');
+    }
+
     # Ignore STDOUT of the child process because older versions of
     # dpkg-source print things out even with -q.
     my $opts = { out => '/dev/null', err => 'unpacked-errors' };
diff --git a/debian/control b/debian/control
index 93e75bf..70cd345 100644
--- a/debian/control
+++ b/debian/control
@@ -55,7 +55,6 @@ Package: lintian
 Architecture: all
 Depends: binutils,
          diffstat,
-         dpkg-dev,
          file,
          gettext,
          intltool-debian,
@@ -73,6 +72,7 @@ Depends: binutils,
          unzip,
          ${misc:Depends}
 Suggests: binutils-multiarch,
+          dpkg-dev,
           libhtml-parser-perl,
           libtext-template-perl,
           man-db (>= 2.5.1-1)
diff --git a/lib/Lintian/Command.pm b/lib/Lintian/Command.pm
index 5317a9b..2994cc0 100644
--- a/lib/Lintian/Command.pm
+++ b/lib/Lintian/Command.pm
@@ -27,7 +27,7 @@ BEGIN {
 
 use base qw(Exporter);
 our @EXPORT = ();
-our @EXPORT_OK = qw(spawn reap kill);
+our @EXPORT_OK = qw(spawn reap kill on_path);
 
 use IPC::Run qw(run harness kill_kill);
 
@@ -333,13 +333,30 @@ sub done {
     }
 }
 
+=head2 C<on_path($command)>
+
+Return true if and only if $command is on the executable search path.
+
+=cut
+
+sub on_path {
+    my $command = shift;
+
+    return 0 unless exists $ENV{PATH};
+    for my $element (split ':', $ENV{PATH}) {
+	next unless length $element;
+	return 1 if -f "$element/$command" and -x _;
+    }
+    return 0;
+}
+
 1;
 __END__
 
 =head1 EXPORTS
 
 Lintian::Command exports nothing by default, but you can export the
-spawn() and reap() functions.
+spawn(), reap(), kill(), and on_path() functions.
 
 =head1 AUTHOR
 

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Message #10 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@ubuntu.com>

Cc: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 08:51:36 -0700

Colin Watson <cjwatson@ubuntu.com> writes:

> We're shipping lintian on Ubuntu CD images as a Recommends of aptdaemon,
> in order to do some basic sanity checks on third-party binary packages.
> Unfortunately this pulls in dpkg-dev and its dependencies, which are
> rather heavyweight.  Some analysis shows that the only thing that we
> need dpkg-dev for is to unpack source packages, so it's possible to
> check binary packages without dpkg-dev.

> The attached patch checks whether dpkg-source is available and produces
> a better error message; it then drops dpkg-dev to a Suggests so that we
> don't have to ship it.  I don't think this should particularly
> negatively affect anyone - if you're building packages, you have
> dpkg-dev installed anyway, and probably not solely by means of
> installing lintian - but I thought I'd file a bug about it rather than
> just committing it so that we could discuss it in case anyone had any
> objections.

Hurm.  I have to admit that this doesn't make me particularly happy, since
checking source packages seems like a fundamental action of Lintian.  The
use of dpkg-dev in Lintian seems to meet the Policy definition of at
*least* Recommends fairly clearly, and Suggests feels much too weak when
we lose that basic of functionality.

On the other hand, I have no alternative solution to your particular
problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
includes build-essential.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #15 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: Russ Allbery <rra@debian.org>

Cc: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 22:00:47 +0100

On Thu, May 12, 2011 at 08:51:36AM -0700, Russ Allbery wrote:
> Hurm.  I have to admit that this doesn't make me particularly happy, since
> checking source packages seems like a fundamental action of Lintian.  The
> use of dpkg-dev in Lintian seems to meet the Policy definition of at
> *least* Recommends fairly clearly, and Suggests feels much too weak when
> we lose that basic of functionality.
> 
> On the other hand, I have no alternative solution to your particular
> problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
> includes build-essential.

Hmm.  I kicked this around with some of my team.  Here are a few
alternatives, all a bit grotty in one way or another:

 * Split lintian into two binary packages, one of which only supports
   checking binary packages, and the other of which (still called
   'lintian') supports everything and depends on the first.

 * Reimplement the small number of checks we consider for this use case
   in aptdaemon or somewhere else.

 * Split out dpkg-source from dpkg-dev.

 * Observe that we already document how to unpack source packages
   without dpkg-dev for users of non-Debian systems (in
   /usr/share/doc/debian/source-unpack.txt - it currently only documents
   format 1.0, but I attached a patch to #579263 some time ago that
   updates this to 3.0), and that therefore this is an interface that
   it's not necessarily too dreadful to reimplement as long as it's
   strictly as a fallback for the case where dpkg-source is not present.

Perhaps oddly, I think the last of those actually strikes me as the
least bad solution, although only because the method is already
documented (modulo that bug report).

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Message #20 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Colin Watson <cjwatson@ubuntu.com>, 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 23:45:03 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2011-05-12 23:00, Colin Watson wrote:
> On Thu, May 12, 2011 at 08:51:36AM -0700, Russ Allbery wrote:
>> Hurm.  I have to admit that this doesn't make me particularly happy, since
>> checking source packages seems like a fundamental action of Lintian.  The
>> use of dpkg-dev in Lintian seems to meet the Policy definition of at
>> *least* Recommends fairly clearly, and Suggests feels much too weak when
>> we lose that basic of functionality.
>>
>> On the other hand, I have no alternative solution to your particular
>> problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
>> includes build-essential.
> 

Hi

> Hmm.  I kicked this around with some of my team.  Here are a few
> alternatives, all a bit grotty in one way or another:
> 
>  * Split lintian into two binary packages, one of which only supports
>    checking binary packages, and the other of which (still called
>    'lintian') supports everything and depends on the first.
> 
>  * Reimplement the small number of checks we consider for this use case
>    in aptdaemon or somewhere else.
> 
>  * Split out dpkg-source from dpkg-dev.
> 

An alternative to this is to use libdpkg-perl to do the unpacking; that
would save some depends of dpkg-dev, assuming the libdpkg-perl API is
stable here.

>  * Observe that we already document how to unpack source packages
>    without dpkg-dev for users of non-Debian systems (in
>    /usr/share/doc/debian/source-unpack.txt - it currently only documents
>    format 1.0, but I attached a patch to #579263 some time ago that
>    updates this to 3.0), and that therefore this is an interface that
>    it's not necessarily too dreadful to reimplement as long as it's
>    strictly as a fallback for the case where dpkg-source is not present.
> 
> Perhaps oddly, I think the last of those actually strikes me as the
> least bad solution, although only because the method is already
> documented (modulo that bug report).
> 

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzFTcAAoJEAVLu599gGRC03AP/2MF6WRnFd3ly81Ov09A8mPS
upDy++pwXnl1kx4Nt7gi22VQnr42M3QrOiBoAF5aMbfrxfbGirTUUZyidx93WivF
iTUcw7xvqxBNxWeSklde89RnpU70VnBq8kxe5luGftoSLbVCljhNlalL6Vp78RxI
c6MKbHPmBUPDMjzcCzOxutJfMUfw8uGj+gSO3qVNK0a0yn0ixeTluV5Qt2TusMNM
DGDRUq3I+vJ6e2AtVuN1hSPlNMvycIR9clfO1znXJ7vSPMbBJ+A1todXfP6wiDPn
YwhlnkU5Torj78mNzNxwcYU6ZIJTIl0gehwH+h1Tbz6jYDpbkycr44MNAf4hhwUy
oow2N1GucG7DpYEs1ZpUd+2TcXtJ7DpUT9Zua04XQnDK2voStd6YJNye2M6btEbp
SkNYEurFZirvTFhFd3LhBlNrqQFBiKIwxcBoJlKpmyce3QBI81DsX+Bq+egnL0xN
YDi8wDoBrg8Aj6HN7iuEj31a/gmbFnW/cBt9IpK8oWyRIkhgND1TsvR1+yc82EKa
/DboxEJ/2yutXvvkaHZhfFEjKk3q5+NMSvm7bOvE3AX7tcT6eKhFUPOQoQmJ+Bis
N8xPIZsD5smNIMg3FO8eDs1AfiSdaSt92ADdcP01K0b9USZjU6DSIsPtfCQIu+EX
8Tf3TzbhYJMXPhUsCNHJ
=SYF0
-----END PGP SIGNATURE-----

Message #25 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@ubuntu.com>

Cc: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 15:00:38 -0700

Colin Watson <cjwatson@ubuntu.com> writes:

> Hmm.  I kicked this around with some of my team.  Here are a few
> alternatives, all a bit grotty in one way or another:

>  * Split lintian into two binary packages, one of which only supports
>    checking binary packages, and the other of which (still called
>    'lintian') supports everything and depends on the first.

This is architecturally tricky, I think, although I've not looked at it in
detail.

>  * Reimplement the small number of checks we consider for this use case
>    in aptdaemon or somewhere else.

I would really like to enable you to use Lintian.  This is exactly the
kind of thing that I'd like to see it be usable for, and the more
different ways we use it, the more resources and bug fixes we get to make
it better for everyone.

>  * Split out dpkg-source from dpkg-dev.

Obviously, this is the simplest solution from the Lintian perspective, but
I doubt the dpkg folks would be particularly thrilled by that additional
complexity for an unusual case.  I'm not sure, though.

>  * Observe that we already document how to unpack source packages
>    without dpkg-dev for users of non-Debian systems (in
>    /usr/share/doc/debian/source-unpack.txt - it currently only documents
>    format 1.0, but I attached a patch to #579263 some time ago that
>    updates this to 3.0), and that therefore this is an interface that
>    it's not necessarily too dreadful to reimplement as long as it's
>    strictly as a fallback for the case where dpkg-source is not present.

We could do this.  My main concern here is that our fallback
implementation will be work to maintain if there are further changes to
the source format (3.0 git, for example), and may have interesting bugs
that are different from those in dpkg-source.  (There are security issues
around this unpacking, for instance.)  But if we only do it as a fallback,
and it came with some tests, this isn't too bad of a solution.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #30 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Thu, 12 May 2011 23:06:31 +0100

On Thu, May 12, 2011 at 11:45:03PM +0200, Niels Thykier wrote:
> On 2011-05-12 23:00, Colin Watson wrote:
> > Hmm.  I kicked this around with some of my team.  Here are a few
> > alternatives, all a bit grotty in one way or another:
> > 
> >  * Split lintian into two binary packages, one of which only supports
> >    checking binary packages, and the other of which (still called
> >    'lintian') supports everything and depends on the first.
> > 
> >  * Reimplement the small number of checks we consider for this use case
> >    in aptdaemon or somewhere else.
> > 
> >  * Split out dpkg-source from dpkg-dev.
> 
> An alternative to this is to use libdpkg-perl to do the unpacking; that
> would save some depends of dpkg-dev, assuming the libdpkg-perl API is
> stable here.

While I agree that this is a further interesting alternative over and
above those I listed, /usr/share/doc/libdpkg-perl/README.api says:

What: libdpkg-perl (perl modules)
Status: stable
Description:
 Among the perl modules provided by libdpkg-perl, you can safely rely on
 those that have $VERSION set to 1.00 (or higher). Note however that the
 API is defined by what's documented in the corresponding manual pages and
 nothing more. You can't assume anything else based on what you read in
 the source code. If you feel the need for further refinements in the
 documented API, don't hesitate to file a wishlist bug against
 libdpkg-perl.
 .
 In case of API-breaking changes, the major number in $VERSION will be
 increased. For API extensions, the minor number will be increased.

The necessary module is /usr/share/perl5/Dpkg/Source/Package.pm, which
has $VERSION set to 0.01 and has no manual page, so according to the
documentation we are not allowed to rely on that being stable yet.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Message #35 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Colin Watson <cjwatson@ubuntu.com>, 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Fri, 13 May 2011 11:19:00 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2011-05-13 00:06, Colin Watson wrote:
> On Thu, May 12, 2011 at 11:45:03PM +0200, Niels Thykier wrote:
>> On 2011-05-12 23:00, Colin Watson wrote:
>>> Hmm.  I kicked this around with some of my team.  Here are a few
>>> alternatives, all a bit grotty in one way or another:
>>>
>>>  * Split lintian into two binary packages, one of which only supports
>>>    checking binary packages, and the other of which (still called
>>>    'lintian') supports everything and depends on the first.
>>>
>>>  * Reimplement the small number of checks we consider for this use case
>>>    in aptdaemon or somewhere else.
>>>
>>>  * Split out dpkg-source from dpkg-dev.
>>
>> An alternative to this is to use libdpkg-perl to do the unpacking; that
>> would save some depends of dpkg-dev, assuming the libdpkg-perl API is
>> stable here.
> 
> While I agree that this is a further interesting alternative over and
> above those I listed, /usr/share/doc/libdpkg-perl/README.api says:
> 
> What: libdpkg-perl (perl modules)
> Status: stable
> Description:
>  Among the perl modules provided by libdpkg-perl, you can safely rely on
>  those that have $VERSION set to 1.00 (or higher). Note however that the
>  API is defined by what's documented in the corresponding manual pages and
>  nothing more. You can't assume anything else based on what you read in
>  the source code. If you feel the need for further refinements in the
>  documented API, don't hesitate to file a wishlist bug against
>  libdpkg-perl.
>  .
>  In case of API-breaking changes, the major number in $VERSION will be
>  increased. For API extensions, the minor number will be increased.
> 
> The necessary module is /usr/share/perl5/Dpkg/Source/Package.pm, which
> has $VERSION set to 0.01 and has no manual page, so according to the
> documentation we are not allowed to rely on that being stable yet.
> 

I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
and he said that the unpacking part of the module was rather stable and
"it's certainly ok as a fallback when dpkg-source is not there".

So as long as we only need dpkg-source -x (and not dpkg-source -b) we
can use libdpkg-perl.

~Niels

For reference, the entire chat:
(11:01:53) nthykier: buxy: Hey, how stable is the API behind
libdpkg-perl Dpkg::Source::Package?  I understand it is not officially
stable, but how far away is it from being stable?
(11:02:18) nthykier: The context being #626476
(11:11:45) buxy: nthykier: quite far in general, as dpkg-source does
much things that are not done in the perl modules, but the part that
deals with unpacking is rather stable, it's certainly ok as a fallback
when dpkg-source is not there
(11:12:11) buxy: (i.e. my first remark applies mainly to dpkg-source -b
and not dpkg-source -x)
(11:12:51) nthykier: Thanks, I will try to setup Lintian with a
libdpkg-perl fall-back then

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzPeEAAoJEAVLu599gGRCE2YQAJLmuGQTGqaNkMZMLHjrO2lN
vod25s54Nz/iwnW/KN2gzTR4BlTbVjhYHQGZK3tA0QJR0PfJmTD6tPTmTFzv7TI/
ZhH68x2h+ZcfncnQa9vWZBsw+A3egM0/UULhBzs03cQRTXu49OK2wxB/N2Dg9Zqc
enAskxsVPeZmUtazfzAo6DV2GtH9k4EfbAMIqGJccIR8JjvK8+Z8CxFst1sqWtjH
7GkFm1+hJW8i5MmU68PbdX8BGRN2YRaRGrmDj+zNtmCS1O9aiCUB1mdALd5KJm9+
p7VsDboqDUuEsPuDYE+BDrwwQYxSNAOApU4k0I/+y171JC5PIhDUpCfxQNDBuSe7
Yfek0SMqm+Ey/9paMMeBlV06XnFditUwXSRZLPwzsP+XQ5Aw/gJPLVtAWDxqKWBc
nEvkYQCvvRMDnu90sps3yuvpy1NJ2/MhU5G2qNTbBmyzvZaMY5ck0JA1uSrbciMl
zcBP695XIG3jhldUgGfbPjDP62uUuioYIP9hfVRy6UyfyCsJ3Auw7JyTfNL625ey
r2lxMqUv6ZJOuMB3qQta5Hvgi+E4MipBJWw7T4svlx709/KNleSzZdZdcRs6yxLY
duHG9El384S6rkAjM2mIMBm34jNP1HXYYKSzTFUfVSqH19WEAvgrtMXg9q+eeJmD
EJvxWDxaspFCPqbV5VGN
=KPwT
-----END PGP SIGNATURE-----

Message #40 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 626476@bugs.debian.org, Colin Watson <cjwatson@ubuntu.com>

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Sat, 14 May 2011 19:50:45 +0200

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2011-05-13 11:19, Niels Thykier wrote:
> On 2011-05-13 00:06, Colin Watson wrote:
>> [...]
> 
> I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
> and he said that the unpacking part of the module was rather stable and
> "it's certainly ok as a fallback when dpkg-source is not there".
> 
> So as long as we only need dpkg-source -x (and not dpkg-source -b) we
> can use libdpkg-perl.
> 
> ~Niels
> 
> [...]
> 

Functional proof-of-concept patch; simply apply and profit!  The code is
stolen from dpkg-source and cooked down a bit (... a lot).

The patch here disables dpkg-source unpacking all together (saves you
from peeling out dpkg-dev from a system).  The patch does not account
for updating the Lintian Depends; I suspect that dpkg-dev should be
replaced with bzip2, xz-utils and libdpkg-perl.  The former two can be
most likely be left out if you know there are no bz2 / xz / lmza sources.

I had to redirect STDOUT of unpacked to keeping it the unpack process
quiet (otherwise it would break the output format of Lintian)[1].

~Niels

[1] Technically there was an API to do it from within libdpkg-perl, but
it was not declared stable, so I went with a redirect instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzsDxAAoJEAVLu599gGRCb6UP/1Vzcdf5ddiyNNVEm+fe2PA8
5trbrJj5CgaCc4+MrmxLxZcHuazaX6A7mpWQ0NokxzGy2r8MmRztv7QQ/GY14m+1
bidbsHIRixwLeHeHB8TDVs1G2aSNke+kWkCP6r8fex7uXi7L8njIiy6epntb9f4a
s70DFwNg0kzXLzrbLah3Cxo/6TNTqXXUEHI8d2mXWVLFeICvJW+wNI2pqjk25Qsg
DpZTmZ3HS719Y66Ta3aVky8KBjGPRQUrqA9bxDu9A95yYgnm7xrSmwOoK6ucpCci
sS1um+lFLOJ95hnpiQJ0BhuplloK+64ja+Lgo01F8N1bg9eKv6vi6421zLBXjJDq
Y2ShnedHnkMn0YURYFEipbs80Fn68jlq8MjaltNiUmYIldiSt74H+IrUXvBRm4ox
BcD+QdwWgl7PUpYi4uYqqkAqp+IXXhJteYrsQM5ZkmIWgVwTmSFrqSr9xJD0ucTr
PSEkXycnfwaDUd6ft57ecrzuN25qpL6mPUch6f1HG8MnB2BXwNqTfVCz9Tau4/Nj
3+9EXFoVuD5axdMSaOQcLRumLIhTDri+B23bTpngUMDFnfj+2mKvvtf3af/+SQuU
wUAhnBH37sPDErjKnnGhpV4BBHF3spdHjL/8Mv869wlc4XN2ViyigBO2LGuNKcah
XhBsmp6qiIQ1RjnUNSeV
=HXyf
-----END PGP SIGNATURE-----

[0001-Sample-patch-to-unpack-using-libdpkg-perl-instead-dp.patch (text/x-patch, attachment)]

[0001-Sample-patch-to-unpack-using-libdpkg-perl-instead-dp.patch.sig (application/octet-stream, attachment)]

Message #45 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Tue, 17 May 2011 17:16:39 +0100

On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
> On 2011-05-13 11:19, Niels Thykier wrote:
> > I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
> > and he said that the unpacking part of the module was rather stable and
> > "it's certainly ok as a fallback when dpkg-source is not there".
> > 
> > So as long as we only need dpkg-source -x (and not dpkg-source -b) we
> > can use libdpkg-perl.
> 
> Functional proof-of-concept patch; simply apply and profit!  The code is
> stolen from dpkg-source and cooked down a bit (... a lot).
> 
> The patch here disables dpkg-source unpacking all together (saves you
> from peeling out dpkg-dev from a system).

That's a bit further than what Raphaël said this API was OK for - not
just "a fallback when dpkg-source is not there".  Have you
double-checked that with him?

> The patch does not account for updating the Lintian Depends; I suspect
> that dpkg-dev should be replaced with bzip2, xz-utils and
> libdpkg-perl.  The former two can be most likely be left out if you
> know there are no bz2 / xz / lmza sources.

Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
xz-utils?

> I had to redirect STDOUT of unpacked to keeping it the unpack process
> quiet (otherwise it would break the output format of Lintian)[1].

You're right that Dpkg::ErrorHandling::report_options isn't marked as
stable, but shouldn't we at least be using options => { quiet => 1 } as
an argument to Dpkg::Source::Package->new as well as this, to match
dpkg-source -q?  It doesn't do much right now, but in principle it seems
as though it might avoid noise on stderr.

> +        libdpkg_unpack_dsc ('dsc', 'unpacked');

Style nit: no space before the open parenthesis.

> +sub libdpkg_unpack_dsc {
> +    my ($dsc, $target) = @_;
> +    require Dpkg::Source::Package;
> +    open(STDOUT, '>', '/dev/null') or fail "Redirecting stdout failed: $!";
> +    # Create the object that does everything
> +    my $srcpkg = Dpkg::Source::Package->new(filename => $dsc);
> +
> +    $srcpkg->check_checksums();
> +
> +    # Unpack the source package (delegated to Dpkg::Source::Package::*)
> +    $srcpkg->extract($target);
> +    return 1;
> +}

This drops the signature check currently performed by dpkg-source, so it
changes Lintian's behaviour to (a) accept .dsc files with bad signatures
and (b) stop issuing a warning for unsigned .dsc files.  This seems
undesirable.

Aside from that, the patch does seem to work as advertised.  Thanks!

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Message #50 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Colin Watson <cjwatson@ubuntu.com>, 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Tue, 17 May 2011 19:05:17 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2011-05-17 18:16, Colin Watson wrote:
> On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
>> On 2011-05-13 11:19, Niels Thykier wrote:
>>> I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
>>> and he said that the unpacking part of the module was rather stable and
>>> "it's certainly ok as a fallback when dpkg-source is not there".
>>>
>>> So as long as we only need dpkg-source -x (and not dpkg-source -b) we
>>> can use libdpkg-perl.
>>
>> Functional proof-of-concept patch; simply apply and profit!  The code is
>> stolen from dpkg-source and cooked down a bit (... a lot).
>>
>> The patch here disables dpkg-source unpacking all together (saves you
>> from peeling out dpkg-dev from a system).
> 
> That's a bit further than what Raphaël said this API was OK for - not
> just "a fallback when dpkg-source is not there".  Have you
> double-checked that with him?
> 

It was not my intention to apply this patch as is.  The argument for
disabling the dpkg-source usage was to ease your job as a tester (so you
did not have to uninstall dpkg-dev from your machines).

>> The patch does not account for updating the Lintian Depends; I suspect
>> that dpkg-dev should be replaced with bzip2, xz-utils and
>> libdpkg-perl.  The former two can be most likely be left out if you
>> know there are no bz2 / xz / lmza sources.
> 
> Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
> xz-utils?
> 

Possibly, I hope some of the other Lintian maintainers have a comment on
this.  Should we just go with Depends: dpkg-dev | libdpkg-perl or do we
want ...

Recommends: dpkg-dev
Depends/Recommends: bzip2, xz-utils

?

>> I had to redirect STDOUT of unpacked to keeping it the unpack process
>> quiet (otherwise it would break the output format of Lintian)[1].
> 
> You're right that Dpkg::ErrorHandling::report_options isn't marked as
> stable, but shouldn't we at least be using options => { quiet => 1 } as
> an argument to Dpkg::Source::Package->new as well as this, to match
> dpkg-source -q?  It doesn't do much right now, but in principle it seems
> as though it might avoid noise on stderr.
>

Sure, I can add that.


>> +        libdpkg_unpack_dsc ('dsc', 'unpacked');
> 
> Style nit: no space before the open parenthesis.
> 

Right...

>> +sub libdpkg_unpack_dsc {
>> +    my ($dsc, $target) = @_;
>> +    require Dpkg::Source::Package;
>> +    open(STDOUT, '>', '/dev/null') or fail "Redirecting stdout failed: $!";
>> +    # Create the object that does everything
>> +    my $srcpkg = Dpkg::Source::Package->new(filename => $dsc);
>> +
>> +    $srcpkg->check_checksums();
>> +
>> +    # Unpack the source package (delegated to Dpkg::Source::Package::*)
>> +    $srcpkg->extract($target);
>> +    return 1;
>> +}
> 
> This drops the signature check currently performed by dpkg-source, so it
> changes Lintian's behaviour to (a) accept .dsc files with bad signatures
> and (b) stop issuing a warning for unsigned .dsc files.  This seems
> undesirable.
> 
> Aside from that, the patch does seem to work as advertised.  Thanks!
> 

Actually as far as I can tell, we do not get any warnings on unsigned
source packages (possibly due to the -q option), but sure, checking
signatures should not be an issue either.

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJN0qrIAAoJEAVLu599gGRCKnwP/09LXM1Ot3G5UGuWXaEESuvO
kfH3/Q7OoGz5oqa3DqkcYcIlyD1cdDwD1f7aJKbVaTtlNa7obwMRNBoO48uDX0Zn
Y205vlnZXUUubyjCrl5c8/JJEoLktRIsZgBMSPBmcOrpEDMunWS64CZbj2B/MZzk
BTzrZrcc/DdvVvuNNbbwM4KNzHUN4l23njsnHI8sTPcpSHQ8xYT5EUxXU0IftEkP
32SSOgQarG4ijRZqDqZWiGuidIhEl5lgLlbN+5ag8ElIcVnAgPZ+LOpPPTDgfsWW
COVOKeKlyZs3qUn5tYS8vOlc3bNnjmhT/g+OgnNdWdLq5iU+LonZFKwYWhRWnOz6
hjC3YaB4MziRYxcjeIZYWxM8vYy/k/QnA7vevip/bQ36UMHTY9dpEvFfVN2RRydl
4RugmVSNGlfkIc0nHT0RCTVfTzQsWpjYRwH/DbIlv4TDg6qkqbZJjmVH4717t1ik
UBtJg842Q5CrMWqCx+6mQ4AZDMhvjZABmzESOpj3vleHRn/RlGANfn5kEZjNlrhN
VhPgO0awx+Rs55mF4Lcb4t8cH089s90enQkCmZklOI1MXlMsnhQol30Ru+rZsjPl
Ipbt0/y6kXtHjxMoRzj6LHq5lUtSsFDuaVod6h8Z81cUEij4cNcwPMXoOamxEfom
Uflp27Q8cRRJ5tYUEJ5N
=I+qh
-----END PGP SIGNATURE-----

Message #55 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: Niels Thykier <niels@thykier.net>

Cc: 626476@bugs.debian.org

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Tue, 17 May 2011 18:26:55 +0100

On Tue, May 17, 2011 at 07:05:17PM +0200, Niels Thykier wrote:
> On 2011-05-17 18:16, Colin Watson wrote:
> > On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
> >> Functional proof-of-concept patch; simply apply and profit!  The code is
> >> stolen from dpkg-source and cooked down a bit (... a lot).
> >>
> >> The patch here disables dpkg-source unpacking all together (saves you
> >> from peeling out dpkg-dev from a system).
> > 
> > That's a bit further than what Raphaël said this API was OK for - not
> > just "a fallback when dpkg-source is not there".  Have you
> > double-checked that with him?
> 
> It was not my intention to apply this patch as is.  The argument for
> disabling the dpkg-source usage was to ease your job as a tester (so you
> did not have to uninstall dpkg-dev from your machines).

Ah, OK.  FWIW I was just temporarily moving /usr/bin/dpkg-source aside
in my earlier tests rather than trying to uninstall the package.

> >> The patch does not account for updating the Lintian Depends; I suspect
> >> that dpkg-dev should be replaced with bzip2, xz-utils and
> >> libdpkg-perl.  The former two can be most likely be left out if you
> >> know there are no bz2 / xz / lmza sources.
> > 
> > Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
> > xz-utils?
> 
> Possibly, I hope some of the other Lintian maintainers have a comment on
> this.  Should we just go with Depends: dpkg-dev | libdpkg-perl or do we
> want ...
> 
> Recommends: dpkg-dev
> Depends/Recommends: bzip2, xz-utils

Neither of those would help my use case, because it would have the
effect of dragging dpkg-dev into our CD images anyway (we install
Recommends by default just as Debian does, and our tools prefer the
first element in a dependency disjunction if it exists).

How about:

  Depends: libdpkg-perl, bzip2, xz-utils
  Suggests: dpkg-dev

or:

  Depends: libdpkg-perl
  [Recommends: bzip2, xz-utils]
  Suggests: dpkg-dev

(Recommends in brackets because libdpkg-perl already recommends those,
so I'm not sure if there's much point in lintian repeating this.)

> > This drops the signature check currently performed by dpkg-source, so it
> > changes Lintian's behaviour to (a) accept .dsc files with bad signatures
> > and (b) stop issuing a warning for unsigned .dsc files.  This seems
> > undesirable.
> > 
> > Aside from that, the patch does seem to work as advertised.  Thanks!
> 
> Actually as far as I can tell, we do not get any warnings on unsigned
> source packages (possibly due to the -q option), but sure, checking
> signatures should not be an issue either.

Oh, you're right, -q would suppress the warning for unsigned files.  I
think my point (a) is still true though.

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Message #60 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Colin Watson <cjwatson@ubuntu.com>

Cc: 626476@bugs.debian.org, Niels Thykier <niels@thykier.net>

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Tue, 17 May 2011 10:49:38 -0700

Colin Watson <cjwatson@ubuntu.com> writes:

> Neither of those would help my use case, because it would have the
> effect of dragging dpkg-dev into our CD images anyway (we install
> Recommends by default just as Debian does, and our tools prefer the
> first element in a dependency disjunction if it exists).

> How about:

>   Depends: libdpkg-perl, bzip2, xz-utils
>   Suggests: dpkg-dev

> or:

>   Depends: libdpkg-perl
>   [Recommends: bzip2, xz-utils]
>   Suggests: dpkg-dev

> (Recommends in brackets because libdpkg-perl already recommends those,
> so I'm not sure if there's much point in lintian repeating this.)

Yeah, one of these look right to me.

Given the number of packages in the archive that use bzip2 compression and
the small size of the bzip2 package, I'd prefer to have it as a strong
dependency.  I don't have a similar opinion about xz-utils, since I don't
have the impression that it's much used yet, so I'd be okay with leaving
that as Recommends.

The choice of whether to explicitly state the Recommends should be based
on whether Lintian ever invokes programs in it directly or via flags to
tar or whether it only invokes it indirectly via libdpkg-perl.  IIRC, we
invoke it directly via a flag to tar.

> Oh, you're right, -q would suppress the warning for unsigned files.  I
> think my point (a) is still true though.

Yeah, we suppress warnings for unsigned source packages since it's very
common to check a source package with Lintian in advance of signing it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #65 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Russ Allbery <rra@debian.org>, 626476@bugs.debian.org

Cc: Colin Watson <cjwatson@ubuntu.com>

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Fri, 20 May 2011 20:52:01 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2011-05-17 19:49, Russ Allbery wrote:
> Colin Watson <cjwatson@ubuntu.com> writes:
> 
>> Neither of those would help my use case, because it would have the
>> effect of dragging dpkg-dev into our CD images anyway (we install
>> Recommends by default just as Debian does, and our tools prefer the
>> first element in a dependency disjunction if it exists).
> 
>> How about:
> 
>>   Depends: libdpkg-perl, bzip2, xz-utils
>>   Suggests: dpkg-dev
> 
>> or:
> 
>>   Depends: libdpkg-perl
>>   [Recommends: bzip2, xz-utils]
>>   Suggests: dpkg-dev
> 
>> (Recommends in brackets because libdpkg-perl already recommends those,
>> so I'm not sure if there's much point in lintian repeating this.)
> 
> Yeah, one of these look right to me.
> 
> Given the number of packages in the archive that use bzip2 compression and
> the small size of the bzip2 package, I'd prefer to have it as a strong
> dependency.  I don't have a similar opinion about xz-utils, since I don't
> have the impression that it's much used yet, so I'd be okay with leaving
> that as Recommends.
> 
> The choice of whether to explicitly state the Recommends should be based
> on whether Lintian ever invokes programs in it directly or via flags to
> tar or whether it only invokes it indirectly via libdpkg-perl.  IIRC, we
> invoke it directly via a flag to tar.
> 

We use it in unpack/unpack-srcpkg-l1 to pass --lzma or --xz to tar.
Other than that, I do not think we use it.  Do you want a
suggests/recommends for this?

>> Oh, you're right, -q would suppress the warning for unsigned files.  I
>> think my point (a) is still true though.
> 
> Yeah, we suppress warnings for unsigned source packages since it's very
> common to check a source package with Lintian in advance of signing it.
> 


In other news, I got the changes mostly done (though alioth is down atm,
so I cannot push them).  For now I have used:

Depends: libdpkg-perl, bzip2
Suggests: dpkg-dev

I was not sure what to do about xz-utils so I left it out for now.

~Niels

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJN1rhMAAoJEAVLu599gGRCu8QQAJBTYVhSN/IJ1BlrwB8aOll+
0/baMJlXzw5W97ReFyYL2gpEBjpELxi/3a/25It+NTrIW3POeb22W+NL2+Q6XRO6
eBvhN0C760TnfILAD39EPAkFGv/yE+OAQmay97R6u0KdcDU8mfcXwi/1EjMaREFc
9aZM+dpwjtulUIZDSEaL6rsci+AwBcGeiJC8Iu+1fft9HF6ewZAC9Qsy3EO+VGGA
EWFzqWRIEgHEgNdvQfDKjO9RqPmcnWsHEnxjklhoJ1C6a8QA3BamC5RX/SOsyejw
cTXTVVr12eIVE294b5BOzk54DsXvXxxaBL2ivp//uVw3P1GF9lDdJ463l8oxs4Hs
9lkuw5WWxk269cGmmIRfjaUszWTXxcY26Zuc3dRIGFArtV+PY1069s0V00KF9i6k
WzFmladrl/HV5yz9XPX6QBZbbP0fE4sKM6EZojNe8a+7rGt6YepeYhkXlA3Zbkp9
+15vN3QlA1diNMlsPJ/qv7nWNClpSmkM4eyVn5ZhLE75PktBSDsMy+Gt9pmIA4kM
MJtqxipSTTHQerd5MG1i4NhnLXameMVDCe1z6xsVapeftEoRScqd2VETyDgHL79I
BwwZ0RoTZ18Mrxv40fmlEh7Du6sxxGdXsipgKDCl1UVxNrqh6SKBC+OrHfZnNTXK
f+d/KVVOiNNQq9/Y6+YW
=3zyx
-----END PGP SIGNATURE-----

Message #70 received at 626476@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Niels Thykier <niels@thykier.net>

Cc: 626476@bugs.debian.org, Colin Watson <cjwatson@ubuntu.com>

Subject: Re: Bug#626476: lintian: reduce dpkg-dev to Suggests

Date: Fri, 20 May 2011 12:51:52 -0700

Niels Thykier <niels@thykier.net> writes:
> On 2011-05-17 19:49, Russ Allbery wrote:

>> The choice of whether to explicitly state the Recommends should be
>> based on whether Lintian ever invokes programs in it directly or via
>> flags to tar or whether it only invokes it indirectly via libdpkg-perl.
>> IIRC, we invoke it directly via a flag to tar.

> We use it in unpack/unpack-srcpkg-l1 to pass --lzma or --xz to tar.
> Other than that, I do not think we use it.  Do you want a
> suggests/recommends for this?

We should probably go with either Suggests or Recommends, then, since we
do invoke it essentially directly.

I think it's okay to leave it as Suggests for right now, at least until xz
is used by more of the archive.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #77 received at 626476-close@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 626476-close@bugs.debian.org

Subject: Bug#626476: fixed in lintian 2.5.1

Date: Wed, 15 Jun 2011 22:18:20 +0000

Source: lintian
Source-Version: 2.5.1

We believe that the bug you reported is fixed in the latest version of
lintian, which is due to be installed in the Debian FTP archive:

lintian_2.5.1.dsc
  to main/l/lintian/lintian_2.5.1.dsc
lintian_2.5.1.tar.gz
  to main/l/lintian/lintian_2.5.1.tar.gz
lintian_2.5.1_all.deb
  to main/l/lintian/lintian_2.5.1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 626476@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Niels Thykier <niels@thykier.net> (supplier of updated lintian package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 15 Jun 2011 23:05:28 +0200
Source: lintian
Binary: lintian
Architecture: source all
Version: 2.5.1
Distribution: unstable
Urgency: low
Maintainer: Debian Lintian Maintainers <lintian-maint@debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Description: 
 lintian    - Debian package checker
Closes: 460350 496902 541978 588831 598412 605012 614876 616493 616553 625886 626476 626587 626597 626775 627082 627431 628673 628754 629056 629189 629193 629288 629453 629648 630164 630560
Changes: 
 lintian (2.5.1) unstable; urgency=low
 .
   * Summary of tag changes:
     + Added:
       - bad-perm-for-file-in-etc-sudoers.d
       - debian-rules-missing-recommended-target
       - dh_pycentral-is-obsolete
       - dh_python-is-obsolete
       - illegal-multi-arch-value
       - non-empty-dependency_libs-in-la-file
     + Removed:
       - uses-dh-python-with-no-pycompat
       - ldconfig-symlink-before-shlib-in-deb
 .
   * checks/binaries:
     + [NT] Applied patch from Paul Wise to detect binaries embeddeding
       glee, glew and libtheora.  (Closes: #629288)
     + [NT] Also consider multiarch dirs when looking for public shared
       libraries.  (Closes: #630164)
   * checks/debhelper{,.desc}:
     + [NT] Recognise that dh_python and dh_pycentral are now obsolete.
       (Closes: #496902, #541978)
   * checks/changes-file:
     + [NT] Always verify the checksums of changes-files.
   * checks/copyright-file:
     + [NT] Extended current dh_make template checks.  Thanks to
       Nelson A. de Oliveira for the patch.  (Closes: #598412)
   * checks/fields{,.desc}:
     + [NT] Allow "all" and "any" to appear together in the Architecture
       field of a .dsc file.  (Closes: #626775)
     + [NT] Added illegal-multi-arch-value.  (Closes: #616493)
   * checks/files:
     + [NT] Fixed two misnamed udeb tags, which lead to an internal
       error if triggered.  Thanks to Guillem Jover for the report.
       (Closes: #628754)
     + [NT] Added bad-perm-for-file-in-etc-sudoers.d tag.
       (Closes: #588831)
     + [CW] Do not issue missing-pre-dependency-on-multiarch-support for
       udebs.
     + [NT] Limit missing-pre-dependency-on-multiarch-support to real
       files only.  Previously it would also check symlinks.
       (Closes: #629648)
   * checks/java{,.desc}:
     + [NT] Sort the jar files by name, so they are checked in the same
       order.
     + [NT] Improved the description of classpath-contains-relative-path.
       (Closes: #629189)
     + [NT] Reduced false-positives of classpath-contains-relative-path.
       Relative classpaths are now okay if they point to jar files in
       /usr/share/java (but not subdirs thereof) and there is a strong
       libX-java dependency.  Alternatively if the classpath points to
       a file or a symlink in the package itself, then it is also okay.
     + [NT] Allow maven plugins to be without classpaths.
       (Closes: #629056)
   * checks/manpages.desc:
     + [ADB] Don't suggest using debmake's output as a reference.  The
       package is not even in oldstable any more.
   * checks/md5sums.desc:
     + [ADB] Drop references to obsolete debstd.  Thanks to Steve Langasek
       for the pointer.
   * checks/rules:
     + [NT] Removed code for handling packages with dh_python.
     + [NT] Fixed the code for determining Build-Depends for python
       packages.  Thanks to Jakub Wilk for the patch.
       (Closes: #614876, #616553)
     + [NT] Applied patch from Roger Leigh to implement the check for
       rules files missing the build-arch and build-indep targets.
       (Closes: #605012)
   * checks/shared-libs{,.desc}:
     + [NT] Added non-empty-dependency_libs-in-la-file.  (Closes: #628673)
     + [NT] Removed ldconfig-symlink-before-shlib-in-deb.
 .
   * collection/java:
     + [NT] Fixed a regex that would accept any file ending with "jar" to
       be a jar file rather than only accepting ".jar".  This fixes a
       number of false-positives java checks.
   * collection/unpacked:
     + [NT] Added support for unpacking source packages using libdpkg-perl,
       instead of dpkg-source, if the latter is not present.
       (Closes: #626476)
 .
   * data/binaries/multiarch-dirs:
     + [NT] New file - maps architectures to multiarch dirs.
   * data/fields/{perl-provides,virtual-packages}:
     + [NT] Refreshed.  (Closes: #627082, #627431)
   * data/output/ftp-master-*:
     + [NT] Refreshed.
   * data/shared-libs/ldconfig-dirs:
     + [NT] Updated ldconfig path for i386 multiarch paths.  Thanks to
       Raphaël Hertzog for the reminder.
   * data/spelling/corrections-multiword:
     + [CW] Remove the "requires to" correction; it has too many common
       false positives, especially involving relative clauses.
       (Closes: #625886)
 .
   * debian/control:
     + [NT] (Build-)Dependency changes.
       - xz-lzma is now preferred to lzma as Build-Dependency
       - Added depends on libdpkg-perl
       - Reduced dpkg-dev to a suggests, we can use libdpkg-perl as
         fallback.
       - Explicitly depends on bzip2 to always support bz2 source packages.
       - Added xz-utils as suggests - needed for .xz source packages.
 .
   * doc/lintian.xml:
     + [NT] Clarify that the package type is not listed in the output for
       binary packages.  (Closes: #629193)
 .
   * frontend/lintian:
     + [NT] Allow some options to be put into the lintianrc file.
       (Closes: #460350)
     + [NT] Added --no-cfg option that can be specified if no config
       file should be read.
     + [NT] Deprecated --checksums (also known as --md5sums and -m).
       Lintian will now always verify the checksums in changes files.
       The options will be accepted with a warning for now, but may
       be removed in a later release.  (Closes: #629453)
     + [NT] Fixed an issue where fail was called before it was
       available.  Thanks to Toby Corkindale for the report.
       (Closes: #630560, LP: #797553)
 .
   * lib/Lintian/Tag/Info.pm:
     + [NT] Output the name of the check and the type of the check
       along with the description of the tag.
   * lib/Lintian/Tags.pm:
     + [NT] Fixed a flaw in logic that gave incorrect results for
       architecture dependent overrides.  Thanks to Andreas Beckmann for
       the report and the patch.  (Closes: #626587)
 .
   * man/lintian.pod.in:
     + [NT] Mentioned that --checksums and aliases are deprecated.
 .
   * unpack/list-srcpkg:
     + [ADB] Don't rely on the order of fields in the Sources file.  The
       files produced by the Debian archive no longer follow the order
       which the code previously assumed, and we shouldn't assume that
       the order won't change again in the future.  (Closes: #626597)
Checksums-Sha1: 
 0b389840ac927017e03373724f1589dcf190025b 2412 lintian_2.5.1.dsc
 f0c1f42f79bbd71a753601495006e77e9df15add 934889 lintian_2.5.1.tar.gz
 b6aae95d8c5f5757f3509f2ce8bfba8fa3c1dbf8 591218 lintian_2.5.1_all.deb
Checksums-Sha256: 
 5a4a013bfd18620e66890d91b35f06a9abe2eedd48a0b04725b6f0bcf72ef4d1 2412 lintian_2.5.1.dsc
 b8812da6a1f31ed462b71d16ab39b491b75291dc7ac40bca629733dffa4726f6 934889 lintian_2.5.1.tar.gz
 b6920d86725fe75f292594356071298fd173b65240159b6a3625bf1fd80174c5 591218 lintian_2.5.1_all.deb
Files: 
 449b2e67a7d792bcbef9203d3dc0f6c7 2412 devel optional lintian_2.5.1.dsc
 8281c27f660386be3cb91dffd58173e6 934889 devel optional lintian_2.5.1.tar.gz
 c34b7b14852cc1abd53d77ee29eb0d26 591218 devel optional lintian_2.5.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJN+StEAAoJEAVLu599gGRC2pwP/j1tf2rT1bW6+EWH+eRgYci0
1/GQ0yBATvyEMxuynn3J0ScKExTuHDoIKEki5ZABpq1DIm1pk4Xao4G2+Fx2W/BB
GHL+7xDEGDdBDBn9CHLJNpeJIaBvZbFqR3O5U55FhHNQTPQqOCO5dY8iNW5wFSnT
DUFezYVHcKWNOaQWy9h9Wk0DGVsn4Dm1aNQG1ZtOpA7r3rs0sd+nA61GoMB8PAVK
IorF1nH1SQQdnJh/23sdc8VaKljc544MootFi+57P0LlAEzQn6eKMLQKEjq1WOHw
5hlM4/D37+xCMHoqrF2yFKdTpOvA1sVxpSatTq1z2NKI3+1uMQnPMlyPshku7EfY
i5lYcJevJ0ux80mlqZ0kW3QZHMhLZutd+rHR7zfeAq/bx+Y4NNAS+Td0NjJsDPt5
GFsoWAGinWSWipsTcovhCQv4jdfk6SjGUxHjhLnXte8zIVesCxVXVoUs2q2iIZWo
qGWSnXjAmPKt1CgiDuXtQniF81gi8B5/4oaGECUrTlZ7VPV04pzXowtaudElC1/t
O6HPkrfrPSFI/jof96mgAJbMaGdw4KH9T55kfXP3f6clkEWfn3b32dFwOEsL4tQc
kC1ehaqjeUXntf5dhuMacBhRWctuvCy1WksXUxHPVfAe20vLel09G/LYa3ErC+Dq
NXbJ1S/NJzjaFWqTEDaR
=hoYp
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.