Debian Bug report logs - #641468
lintian: update the lab layout (i.e. use pools)

Toggle useless messages

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

From: Niels Thykier <niels@thykier.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lintian: update the lab layout (i.e. use pools)

Date: Tue, 13 Sep 2011 18:04:15 +0200

Package: lintian
Severity: important


Jakub realized the source of a lot of our errors on lintian.d.o are
caused by limitations in the file-system.  We should probably use
a pool or something similar to reduce the amount of elements in
each dirs.

~Niels

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

From: Jakub Wilk <jwilk@debian.org>

To: 641468@bugs.debian.org

Subject: Re: Bug#641468: lintian: update the lab layout (i.e. use pools)

Date: Tue, 13 Sep 2011 19:21:35 +0200

* Niels Thykier <niels@thykier.net>, 2011-09-13, 18:04:
>Jakub realized the source of a lot of our errors on lintian.d.o are 
>caused by limitations in the file-system.  We should probably use a 
>pool or something similar to reduce the amount of elements in each 
>dirs.

Just to shed more light on what the problem is:

$ stat /srv/lintian.debian.org/laboratory/binary/ | grep Links
Device: 807h/2055d	Inode: 7512069     Links: 32000

On ext3 filesysytem, at least in squeeze, 32K is hard limit on number of 
hard links, so we can't create more directories in binary/.

ext4 doesn't have this limitation, so a work-around would be to convert 
the filesystem.

-- 
Jakub Wilk

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

From: Niels Thykier <niels@thykier.net>

To: 641468@bugs.debian.org

Subject: Re: Bug#641468: lintian: update the lab layout (i.e. use pools)

Date: Wed, 14 Sep 2011 12:34:16 +0200

On 2011-09-13 19:21, Jakub Wilk wrote:
> * Niels Thykier <niels@thykier.net>, 2011-09-13, 18:04:
>> Jakub realized the source of a lot of our errors on lintian.d.o are
>> caused by limitations in the file-system.  We should probably use a
>> pool or something similar to reduce the amount of elements in each dirs.
> 
> Just to shed more light on what the problem is:
> 
> $ stat /srv/lintian.debian.org/laboratory/binary/ | grep Links
> Device: 807h/2055d    Inode: 7512069     Links: 32000
> 
> On ext3 filesysytem, at least in squeeze, 32K is hard limit on number of
> hard links, so we can't create more directories in binary/.
> 
> ext4 doesn't have this limitation, so a work-around would be to convert
> the filesystem.
> 

Upgrading to ext4 might be a solution, but I personally think that
changing the Lab layout is the "right thing(tm)" to do in this case.
Considering we want derivatives to do archive-wide Lintian runs, it may
be prudent to be file-system agnostic.

Also, we can (ab)use this oppertunity to enable "multi-version" +
"multi-architectures" in static labs as well.  Hopefully we can also
clean up the Lab API while we are at it. XD

~Niels

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

From: Niels Thykier <niels@thykier.net>

To: 641468@bugs.debian.org

Subject: Re: Bug#641468: lintian: update the lab layout (i.e. use pools)

Date: Thu, 15 Sep 2011 17:17:31 +0200

On 2011-09-14 12:34, Niels Thykier wrote:
> On 2011-09-13 19:21, Jakub Wilk wrote:
>> * Niels Thykier <niels@thykier.net>, 2011-09-13, 18:04:
>>> Jakub realized the source of a lot of our errors on lintian.d.o are
>>> caused by limitations in the file-system.  We should probably use a
>>> pool or something similar to reduce the amount of elements in each dirs.
>>
>> Just to shed more light on what the problem is:
>>
>> $ stat /srv/lintian.debian.org/laboratory/binary/ | grep Links
>> Device: 807h/2055d    Inode: 7512069     Links: 32000
>>
>> On ext3 filesysytem, at least in squeeze, 32K is hard limit on number of
>> hard links, so we can't create more directories in binary/.
>>
>> ext4 doesn't have this limitation, so a work-around would be to convert
>> the filesystem.
>>
> 
> Upgrading to ext4 might be a solution, but I personally think that
> changing the Lab layout is the "right thing(tm)" to do in this case.
> Considering we want derivatives to do archive-wide Lintian runs, it may
> be prudent to be file-system agnostic.
> 
> Also, we can (ab)use this oppertunity to enable "multi-version" +
> "multi-architectures" in static labs as well.  Hopefully we can also
> clean up the Lab API while we are at it. XD
> 
> ~Niels
> 
> 
> 
> 

Okay, so before diving into this - can anyone elaborate on the current
Lab design?  The User Manual does not give me a lot here.  I am asking
because I want to know if there is something we should pay attention to
when working on this.


Beyond this I have been spending some time looking at the situation and
possible solutions and extensions.  My basic does not affect the layout
of entries/unpacked packages (i.e. collections should be unaffected).
  It appears that we have been bumping the LAB_FORMAT about once a year
the last two years (in 01-2010 for changes and 03-2003 due to "many
recent changes"[LFB]).  Hopefully format 11 can last far longer than a
year. :)

So, simple solution is to use a "mirror-like" pool, so something like:

 $LINTIAN_LAB/pool/l/lintian/lintian_2.5.3_all_binary/
 $LINTIAN_LAB/pool/l/lintian/lintian_2.5.3_source/

The last entry would be "${name}_${version}(_${arch})_${type}", where
the ${arch} part is not relevant for source.  Not sure what to do about
changes and architecture though (as they may have multiple architectures).
  The above have the advantage of trivially allowing multiple versions
(and architectures) of the same package in the pool.

I am thinking this would be a good time to make the Lab maintain its own
state files (info/$type-packages).  This implies updating the state
files when adding or removing a package from the lab.  If the lab
maintains these, we will most likely have an easier time providing a
sane API for accessing packages in the Lab.
  If we go down this route I would probably use the oppertunity to empty
the "standards-version" and the "architecture" field in
info/source-packages.
  Furthermore, each entry in these files have enough information to
provide create a "Lintian::Processable".  If we extend L::Processable we
could be looking at a "standard" way of requesting and submitting
packages to the Lab.

I also consider the option of creating a "migration utility" that could
upgrade a LAB_FORMAT 10 to 11.  Since we have gotten rid of the unpack
scripts and "cross-package" symlinks, this change will basically just be
a bunch of "mkdir" followed by a tons of "mv" (and updating the
Lab-Format in the ".lintian-status" file).
  Admittedly lintian.d.o probably has relatively little to gain from it
as we will need to doing a full run once this bug is fixed anyway.


~Niels

[LFB] Commits:
fc10b608
8b1f0cfe

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

From: Niels Thykier <niels@thykier.net>

To: 641468@bugs.debian.org

Subject: Re: Bug#641468: lintian: update the lab layout (i.e. use pools)

Date: Wed, 05 Oct 2011 10:45:52 +0200

On 2011-09-13 18:04, Niels Thykier wrote:
> Package: lintian
> Severity: important
> 
> 
> Jakub realized the source of a lot of our errors on lintian.d.o are
> caused by limitations in the file-system.  We should probably use
> a pool or something similar to reduce the amount of elements in
> each dirs.
> 
> ~Niels
> 
> 
> 

I guess it might be a good time for a little status update here.

The lab-refactor branch is now working for "simple" use cases[1].
However, the lintian.d.o-style usage needs some attention.

In the master branch we use $lab/info/* as a list of "what was in the
mirror last time we checked".  Those files have been repurposed in the
lab-refactor branch, where their new meaning is "what is currently in
the lab".  This means that "dist" search[2] is currently broken.
  To my knowledge there are *2* known cases where "dist" searches make
sense - lintian.d.o and lintian.debathena.o.  I feel we should move that
functionality to a new frontend (such as the "lintian-harness"[3]) that
would focus lintian.d.o-like setups.

Note that "repurposing" is not entirely complete and therefore
reporting/harness is more or less broken right now.  One of the issues
is that unpack/* still use the files in info/* as a dist list and not a
lab list.


I also considered adding a file in info/ to keep track of lab-wide
(meta)data, such as the lab-format.  In the old lab format, this is
stored in every entry.  This makes is slightly more difficult to check
if we are dealing with a compatible lab.
  Consider if you use an "old" lintian to use the new lab style - they
do not store the entries the same place, so it has no reliable way to
detect it is not compatible.  I would prefer that an old lintian would
always be able to say "The lab uses a newer lab-format that this version
of lintian supports" - even if this case will "probably never happen".


I am also wondering what we need in the "per-entry" lintian-status file.
 In the master branch, we store Lintian-Version, Lab-Format, Package
(name), Version (package), Type (package) and Timestamp.
  When we read the status file, we compare lab-format, package version
and timestamp.  With the changes in lab-refactor branch, the lab always
supports multiple versions of the same package, thus the package version
comparision is a no-op.

As I understand it, the timestamp is there to make lintian "re-unpack"
the package if it changed since the last run.  Currently it completely
removes the entry if the timestamp does not "match".  Though this code
only makes sense for "personal" static labs - on the lintian.d.o case,
the version of a package can not be reused (at least not in general).
  The timestamp-part is not in the lab-refactor branch (yet?).

I am considering to replace the "Lab-format" value with an
"entry-format-version".  Not sure it makes sense, but I thinking it may
make migration to newer formats easier.
  If I had not (ab)used the oppertunity to do optimizations in the
.lintian-status file (see below), the migration from the current to the
lab-format would basically just have been a bunch of "mv X Y" + updating
info/*.

Finally, I have added a "Collections" entry to the .lintian-status file.
 This is used to keep track of which collections have been run and
removes the need for ".$coll-$ver" files.
  This will reduce our (expected) file-creation from 18 to 1 per binary
package[4].  For a full mirror run 18 files per binary package roughly
translate to 630 000 files[5].  The udeb and sources we go from 10 and 8
to 1.


So to sum it up:  I am repurposing $lab/info/* files to be a manifest of
what is in the lab (rather than what is on the mirror).  I am breaking
"dist" search and suggest we create a separate frontend for
archive-checks that supports "dist" search.
  I am considering to add a metadata file in $lab/info/ to include stuff
like "Lab format" version.  I have removed data from the (per-entry)
.lintian-status files.  The (per-entry) ".$coll-$ver" files will be
removed and the .lintian-status file will track those.

Any comments?  If not I will (hopefully) get the branch ready to be
merged into master within 2-3 weeks - so if you have not reviewed the
branch yet, now would be a good time to start.  :)

~Niels

[1] That would be single package checks:
lintian $pkg

but also simple static-lab usage

lintian --lab $lab --setup-static
lintian --lab $lab --unpack $pkg[,..., $pkgN]
lintian --lab $lab -r $pkg[,..., $pkgN]
etc.

[2] The "check packages from mirror" search, i.e.

lintian --lab $lab $pkg[,...,$pkgN]

will first check the mirror and then fallback to the lab.  I suggest we
only check the lab in this case.

[3] http://lists.debian.org/debian-lint-maint/2011/08/msg00285.html

[4] 17 binary collections + 1 lintian status file.

[5]  Assumes 35 000 binary packages.  Though currently "only" 576 000
files are created due to the file system limitations (~32 000 binary
packages).

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

From: Niels Thykier <niels@thykier.net>

To: 641468@bugs.debian.org

Subject: Re: Bug#641468: lintian: update the lab layout (i.e. use pools)

Date: Wed, 26 Oct 2011 12:01:11 +0200

On 2011-10-05 10:45, Niels Thykier wrote:
> On 2011-09-13 18:04, Niels Thykier wrote:
>> Package: lintian
>> Severity: important
>>
>>
>> Jakub realized the source of a lot of our errors on lintian.d.o are
>> caused by limitations in the file-system.  We should probably use
>> a pool or something similar to reduce the amount of elements in
>> each dirs.
>>
>> ~Niels
>>
>>
>>
> 
> I guess it might be a good time for a little status update here.
> 

Since no one has commented so far I have applied do-cracy and done stuff...

> The lab-refactor branch is now working for "simple" use cases[1].
> However, the lintian.d.o-style usage needs some attention.
> 
> In the master branch we use $lab/info/* as a list of "what was in the
> mirror last time we checked".  Those files have been repurposed in the
> lab-refactor branch, where their new meaning is "what is currently in
> the lab".  This means that "dist" search[2] is currently broken.
>   To my knowledge there are *2* known cases where "dist" searches make
> sense - lintian.d.o and lintian.debathena.o.  I feel we should move that
> functionality to a new frontend (such as the "lintian-harness"[3]) that
> would focus lintian.d.o-like setups.
> 
> Note that "repurposing" is not entirely complete and therefore
> reporting/harness is more or less broken right now.  One of the issues
> is that unpack/* still use the files in info/* as a dist list and not a
> lab list.
> 

"dist" search is now removed from lintian - the reporting stuff left
untouched and is therefore still broken.  Yay for progress! :)

When I was looking at this, I realised two things.  First a lot of
variables (and cmd-options) now appear to be redundant in
frontend/lintian.  Namely all of LINTIAN_{ARCHIVEDIR,AREA,DIST} and
possibly also LINTIAN_ARCH.  It has not been double checked, but I
strongly suspect them of being unused now.

Secondly, the current "search" rules were not sufficient.  Basically, it
was only possible to match "all" packages with a given name.  I have
solved this by creating a simple way of referring to packages in the Lab.

Originially I planned to accept both the current "britney-style"
format[1] and the "filename-style"[2].  However it occurred to me that
the "filename-style" is (for obvious reasons) impossible to reliably
distinguish from a normal file.  As this could lead to confusion for the
users (i.e. principe of "least surprise"), I decided to not include the
"filename-style".  The "britney-style" format is described in
man/lintian.pod.in.

[1] [type:]package[/version[/arch]]

[2] package_version[_arch].ext

> 
> I also considered adding a file in info/ to keep track of lab-wide
> (meta)data, such as the lab-format.  In the old lab format, this is
> stored in every entry.  This makes is slightly more difficult to check
> if we are dealing with a compatible lab.
>   Consider if you use an "old" lintian to use the new lab style - they
> do not store the entries the same place, so it has no reliable way to
> detect it is not compatible.  I would prefer that an old lintian would
> always be able to say "The lab uses a newer lab-format that this version
> of lintian supports" - even if this case will "probably never happen".
> 

I have added a lab-wide data file stored as "$LAB/info/lab-info".  It
uses the deb822-style syntax and has two fields in the first paragraph:

"""
Lab-Format: $format
Layout: pool
"""

The Lab-Format field describes the current format of the lab[3].  The
Layout field describes how the packages are placed in the lab.
Currently only one layout exists (namely "pool"), which reflects the
layout in the current branch.
  The Layout field allows us to implement and play with a new layout
side-by-side with the current one.  Hopefully we will never need this
feature, but probably we will.

[3] Will be 11 when the development is done.  Currently it is 10.1.

> 
> I am also wondering what we need in the "per-entry" lintian-status file.
>  In the master branch, we store Lintian-Version, Lab-Format, Package
> (name), Version (package), Type (package) and Timestamp.
>   When we read the status file, we compare lab-format, package version
> and timestamp.  With the changes in lab-refactor branch, the lab always
> supports multiple versions of the same package, thus the package version
> comparision is a no-op.
> 
> As I understand it, the timestamp is there to make lintian "re-unpack"
> the package if it changed since the last run.  Currently it completely
> removes the entry if the timestamp does not "match".  Though this code
> only makes sense for "personal" static labs - on the lintian.d.o case,
> the version of a package can not be reused (at least not in general).
>   The timestamp-part is not in the lab-refactor branch (yet?).
> 
> I am considering to replace the "Lab-format" value with an
> "entry-format-version".  Not sure it makes sense, but I thinking it may
> make migration to newer formats easier.
>   If I had not (ab)used the oppertunity to do optimizations in the
> .lintian-status file (see below), the migration from the current to the
> lab-format would basically just have been a bunch of "mv X Y" + updating
> info/*.
> 


I have decided to keep the redundant package information (package,
version and type), plus I added architecture (for non-source packages).
 I realised that it may allows us to implement consistency checks later,
which is probably a "good thing".

The per-entry files also carry a new version, namely "Lab-Entry-Format".
 This version describes how entries are stored and is "generally"
disjoined from the Layout and the Lab-Format.

The "Lab-Format" and the "Timestamp" field have been removed.


> [...]
> 
> Any comments?  If not I will (hopefully) get the branch ready to be
> merged into master within 2-3 weeks - so if you have not reviewed the
> branch yet, now would be a good time to start.  :)
> 

Yeah, so "2-3 weeks" is slightly off, but there is still progress.

> ~Niels
> [...]

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

From: Niels Thykier <niels@thykier.net>

To: 641468-close@bugs.debian.org

Subject: Bug#641468: fixed in lintian 2.5.4

Date: Mon, 21 Nov 2011 23:03:27 +0000

Source: lintian
Source-Version: 2.5.4

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.4.dsc
  to main/l/lintian/lintian_2.5.4.dsc
lintian_2.5.4.tar.gz
  to main/l/lintian/lintian_2.5.4.tar.gz
lintian_2.5.4_all.deb
  to main/l/lintian/lintian_2.5.4_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 641468@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: Mon, 21 Nov 2011 23:05:12 +0100
Source: lintian
Binary: lintian
Architecture: source all
Version: 2.5.4
Distribution: unstable
Urgency: medium
Maintainer: Debian Lintian Maintainers <lintian-maint@debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Description: 
 lintian    - Debian package checker
Closes: 387166 580048 580945 582511 604620 613327 616436 633507 636599 637540 641035 641468 641609 641983 642027 642038 642092 642113 642125 642339 642902 643009 643205 643714 643716 644021 644339 644344 644488 644556 644793 645393 645438 645660 646126 646420 646495 646529 646604 646817 646838 647227 647250 648117 648350 648532 649133 649329
Changes: 
 lintian (2.5.4) unstable; urgency=medium
 .
   The "perl5.14 (+ misc) fix"-upload.  Medium as perl 5.14
   deprecation warnings tend to make Lintian output unreadable.
 .
   * Summary of tag changes:
     + Added:
       - data.tar.xz-member-without-dpkg-pre-depends
       - gzip-file-is-not-multi-arch-same-safe
       - init.d-script-does-not-implement-optional-option
       - init.d-script-missing-lsb-description
       - maintainer-address-causes-mail-loops-or-bounces
       - missing-build-dependency-for-dh-addon
       - package-depends-on-lower-priority-package
       - package-would-benefit-from-build-arch-targets
       - python-depends-but-no-python-helper
       - python3-depends-but-no-python3-helper
       - transitional-package-should-be-oldlibs-extra
       - uploader-address-causes-mail-loops-or-bounces
 .
   * checks/*:
     + [JW] Replace common_data.pm with Lintian::Check.
     + [NT] Remove some unused "use lib <expr>" from various checks.
     + [NT] Use Lintian::Collect::Group to find direct dependencies.
   * checks/binaries:
     + [JW] Allow binaries to use "/usr/lib/$srcpkg/" in RPATHs.
       (Closes: #642092)
     + [JW] Fixed a false-positive when using the multiarch dir in
       RPATH.  (Closes: #646817)
   * checks/changes-file{,.desc}:
     + [NT] Added the "precise" to the list of Ubuntu distributions.
       Thanks to Loïc Minier for the patch.
     + [NT] Accept release codename in the changes file.  Thanks to
       Julien Cristau for the report.  (Closes: #637540)
   * checks/circular-deps{,.desc}:
     + [NT] Renamed to group-checks{,.desc}.
   * checks/group-checks{,.desc}:
     + [NT] Added check for depending on lower priority packages built
       from the same source.  Only strong dependencies are considered.
       Thanks to Neil Williams for the report.  (Closes: #387166)
   * checks/common_data.pm:
     + [JW] Merged into Lintian::Check.
   * checks/cruft{,.desc}:
     + [NT] Escape path when using them in regexes.  (Closes: #642902)
     + [NT] Extended the description of the tag for non-native packages
       with native versions.  Thanks to Jari Aalto for the report.
       (Closes: #580048)
   * checks/copyright.desc:
     + [RG,NT] Clarified that the PHP 2.x license is only for the PHP
       interpreter and PEAR modules cannot use it.  Thanks to
       Thomas Goirand for the report.  (Closes: #616436)
   * checks/deb-format{,.desc}:
     + [NT] Added check for using .xz compression in deb files without
       versioned Pre-Depends on dpkg.  The severity is pedantic for
       Debian and serious for Ubuntu.  Thanks to Aaron M. Ucko for the
       rapport.  (Closes: #648350)
   * checks/dehelper{,.desc}:
     + [JW,NT] Check for versioned dependencies for some dh_commands.
       (Closes: #641035)
     + [JW] Detect missing dependencies for using dh sequences.
       (Closes: #613327)
     + [JW] Parse continuation lines in d/rules.
     + [JW] Only emit brace-expansion-in-debhelper-config-file at most
       once per file.  (Closes: #644344)
     + [JW] Replaced "=" with " => " in the tag extra for missing-
       build-dependency-for-dh_-command to improve readability.  This
       breaks overrides, but according to lintian.d.o there are none
       of these.  (Closes: #644339)
     + [JW] Added check for missing python helpers when using python
       substvars in d/control.  (Closes: #582511)
   * checks/fields{,.desc}:
     + [NT] Fixed source-field-does-not-match-pkg-name.
     + [NT] Newlines from URIs in Vcs-* fields are stripped before they
       are checked.  These will fields will also cause a "multiline-
       field" tag if they contain newlines.
     + [JW,NT] Clarified that build-depends-on-metapackage is not only
       triggered by X11 metapackages.  (Closes: #642125)
     + [NT] Ensure transitional packages are in section oldlibs and
       priority extra.  Thanks to Josh Triplett for the report.
       (Closes: #645438)
     + [NT] Check for bouncing and looping email addresses.  Thanks to
       Ansgar Burchardt and Arno Töll for the bug report and patch.
       (Closes: #636599)
   * checks/files{,.desc}:
     + [JW] Suggest the usage of "-delete" rather than "| xargs rm -f".
       (Closes: #641983)
     + [JW] Improve "linked against libvga.so" test.  This avoid
       setuid-binary false-positives.  (Closes: #642038)
     + [NT] Skip package-contains-no-arch-dependent-files for
       transitional packages.  Thanks to Andreas Beckmann for the patch.
       (Closes: #642339)
     + [NT] Applied patch from Andrew Starr-Bochicchio to update the
       description of font-in-non-font-package to better reflect current
       font policy.  (Closes: #646838)
     + [JW,NT] Check that gzip files are compressed with -n in
       "Multi-Arch: same" packages.  (Closes: #649329)
       packages.
     + [NT] Corrected perl4 check, thanks to Dominic Hargreaves for the
       report and the patch.
   * checks/init.d{,.desc}:
     + [NT] Applied patch from Peter Eisentraut to detect init.d scripts
       without support for the optional "status" option.
       (Closes: #647250)
     + [NT] Fixed deprecation warning when using perl 5.14.
       (Closes: #649133)
     + [NT] Added tag for missing LSB Description keyword.  Thanks to
       Michael Biebl and Petter Reinholdtsen for the bug report.
       (Closes: #604620)
   * checks/rules{,.desc}:
     + [JW] Fixed false negative "missing-build-dependency" when using
       "dh --with=X" rather than "dh --with X".  (Closes: #643714)
     + [NT] Do not emit missing-build-dependency for missing dh sequences,
       since the new tag will handle those.
     + [JW] Parse continuation lines in d/rules.  (Closes: #644021)
     + [JW] Check for versioned dependency on dpkg-dev when using the new
       dpkg makefiles.  (Closes: #646495)
     + [NT] Added tracker tag for the build-arch target goal.
       (Closes: #647227)
     + [JW] Fixed duplicate tags about missing dependency for
       dh_pycentral/dh_pysupport.  (Closes: #633507)
   * checks/scripts:
     + [RA] Exclude files ending in *.erb from several shell script
       checks.  ERB is a Ruby templating language, so these will probably
       have mixed shell and Ruby code and may not be executable.  Thanks,
       Laurent Arnoud.
     + [NT] Corrected perl4 check, thanks to Dominic Hargreaves for the
       report and the patch.  (Closes: #648532)
   * checks/source-copyright:
     + [JW] Added some more DEP-5 URLs.  (Closes: #642027)
     + [JW] Improved the wording of the extra information for the tag
       syntax-error-in-dep5-copyright.  (Closes: #644556)
   * checks/symlinks:
     + [NT] Ignore broken links that appears to point to fonts.
 .
   * collection/index:
     + [NT] Fixed an "uninitialized variable" warning if no tarballs were
       present or the tarball is empty.  (Closes: #645660, LP: #886487)
     + [NT] Fixed deprecation warning when using perl 5.14.
   * collcetion/debfiles:
     + [NT] Bail if the debian dir is a symlink.
 .
   * data/changelog-file/debian-dists:
     + [NT] New file.
   * data/changelog-file/ubuntu-dists:
     + [NT] Added the "precise".  Thanks to Loïc Minier for the
       patch.  (Closes: #644488)
   * data/debhelper/{dh_commands,maint_commands,miscDepends_commands}:
     + [NT] Refreshed.
   * data/debhelper/alt-dh_commands:
     + [NT] Renamed to dh_commands-manual.
   * data/debhelper/dh_commands-manual:
     + [NT] Support arbitrary dependency relations.  This new change
       also fixes a "duplicate" in the dependency output.
       (Closes: #643716)
   * data/fields/essential:
     + [NT] Add libc-bin to the list of known essential packages.
   * data/fields/obsolete-packages:
     + [NT] Added dpatch per request of the maintainer.  Thanks to
       Gergely Nagy for the report.  (Closes: #646420)
   * data/fields/virtual-packages:
     + [NT] Refreshed against sid.  Thanks to Gregor Herrmann for the
       report.  (Closes: #646604)
   * data/rules/deprecated-makefiles:
     + [JW] Added dbs makefiles, since dbs maintainer deprecated the
       package in 0.47.  (Closes: #646126)
   * data/shared-libs/ldconfig-dirs:
     + [NT] Add multi-arch dirs for hurd-i386.  Thanks to Julien
       Cristau for noticing that they were missing.
   * data/spelling/corrections:
     + [NT] Added a correction for "propagate" and "separate", thanks
       to Guillem Jover for the suggestions.
       (Closes: #644793, #646529)
     + [JW] Added a number of corrections.  (Closes: #645393)
 .
   * debian/control:
     + [CW] Mark lintian Multi-Arch: foreign (there does exist one
       Architecture: any package that Build-Depends: lintian, so this helps
       multiarch cross-building slightly).
   * debian/lintian.install:
     + [NT] Removed unpack which was removed.
 .
   * frontend/lintian:
     + [NT] Collections explicitly requested (by -U) are no longer
       auto-removed.  Previously the only way to prevent auto-removal
       was to use --keep-lab.
     + [NT] Removed all archive-wide testing code.  This has been moved
       into reporting/harness.  This deprecates a lot options and config
       variables (--arch, --archivedir, --area, --dist, --section and
       LINTIAN_{ARCH,ARCHIVEDIR,AREA,DIST}).
     + [NT] Support new lab query format, replacing the old "package
       name"-based search.
 .
   * lib/Lab{,/Package}.pm:
     + [NT] Removed, replaced by Lintian::Package{,::Entry}.
   * lib/Lintian/Check.pm:
     + [JW] Merged with common_data.pm.
   * lib/Lintian/Collect/Group.pm:
     + [NT] New file - Collect like API for group data.
   * lib/Lintian/Collect/Source.pm:
     + [JW] Fixed call to binary_field in binary_relation.
       (Closes: #641609)
   * lib/Lintian/Data.pm:
     + [NT] Fixed a file descriptor leak.
   * lib/Lintian/Lab{,/Entry,/Manifest,/ManifestDiff}.pm:
     + [NT] New files.  Replaces the Read_pkglists, Lab and
       Lab::Package modules.
   * lib/Lintian/Lab.pm:
     + [JW,NT] Correctly handle $TMPDIR not being an absolute path.
       (Closes: #642113)
     + [NT] New lab layout style resembling the "pool" dirs of the
       Debian mirrors.  This allows more than 32 000 packages of a
       given type in the laboratory.  It also allows multiple
       versions/architectures of the same package in static labs.
       A feature previously only enabled in temporary labs.  The new
       layout is incompatible with the old format.  (Closes: #641468)
   * lib/Lintian/Output.pm:
     + [NT] Minor refactoring to simplify creation of the FullEWI
       module.
   * lib/Lintian/Output/FullEWI.pm:
     + [NT] New experimental output.  More machine-friendly version
       of the normal Lintian output format.
   * lib/Lintian/Output/XML.pm:
     + [NT] Use self-closing tags (if possible) and do not write
       attributes with an empty value.
   * lib/Lintian/Processable.pm:
     + [NT] Reduced to an abstract class.  The "old" implementation
       has been put into Lintian::Processable::Package.
   * lib/Lintian/Processable/Package.pm:
     + [NT] New file.
     + [NT] Changed the "name" of changes files.  It is now equal to
       the name of the source package.  Previously it was the filename
       (without extension and without the dir part).
   * lib/Read_pkglists.pm:
     + [NT] Removed - replaced by Lintian::Lab::Manifest.
   * lib/Util.pm:
     + [NT] Stricten the parser to not accept a field name with a ":".
       This could cause the parser to eat the first part of the value,
       if it contained a colon and there was no space before the value.
       Thanks to Pino Toscano for reporting the issue.
     + [JW] Explicitly check that files are not encoded using ISO-2022,
       when they should be encoded with UTF-8.  (Closes: #643009)
     + [JW] Use "paragraph" and "field" rather than "section" and "tag"
       when referring to a Debian control file.
 .
   * man/lintian.pod.in:
     + [NT] Fixed a typo, thanks to Evgeni Golov for spotting it,
 .
   * private/generate-lintian-pod:
     + [NT] Document which collections are auto-removed by default in
       static labs.
 .
   * profiles/ubuntu/main.profile:
     + [NT] Disable no-upstream-changelog and lzma-deb-archive for
       Ubuntu.  Thanks to Evan Broder for the report and patch.
       (Closes: #648117)
 .
   * reporting/*:
     + [NT] Recognise and display pedantic tags.
     + [JW] Only emit "plus X overrides" if there any overrides.
   * reporting/{harness,html_reports}:
     + [NT] Do not accept LINTIAN_UNPACK_LEVEL nor LINTIAN_SECTION
       anymore.  The lintian frontend lost support for these in
       2.5.0~rc3.
   * reporting/harness:
     + [NT] Refactored to handle the archive-wide checking directly.
     + [NT] Use the new FullEWI output format for the archive-wide
       logs.
   * reporting/html_reports:
     + [NT] Ensure source tags appear before binary tags.
       (Closes: #580945)
     + [NT] Supports the FullEWI output format.
 .
   * t/*:
     + [NT] Skip some tests broken by a recent dpkg upload.
       (Closes: #643205)
 .
   * unpack/*:
     + [NT] Removed, no longer used.
Checksums-Sha1: 
 7675c6e81265bb42e0ab12e66c8e27cf99ecc0e7 2387 lintian_2.5.4.dsc
 8f5cd16df9c948e77e2c004a985662c0fb04c3e8 1031662 lintian_2.5.4.tar.gz
 31d8a18f15eaba580cf2a2f89e4ed42d58499801 648794 lintian_2.5.4_all.deb
Checksums-Sha256: 
 9270906fcde59fa43a6fea7c79e9b9e1141fbd51b172f7348181ab4d3eb40e31 2387 lintian_2.5.4.dsc
 09fd107c18dc3be0df777ff0dbe2b7706c9494fee6cd6460dd5a9e6ffdd8df97 1031662 lintian_2.5.4.tar.gz
 44b1670e79327b01f994bd9b0c739f02d33c9ea8a6b642e4b68c231cbd30191b 648794 lintian_2.5.4_all.deb
Files: 
 50bb02eee117a5884df961911052b20a 2387 devel optional lintian_2.5.4.dsc
 d38e5c6ba52ccf128cfe7f1f8ce11c0f 1031662 devel optional lintian_2.5.4.tar.gz
 5a4514b5a4a56ec3597f4445a9c0e6d8 648794 devel optional lintian_2.5.4_all.deb

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

iQIcBAEBCAAGBQJOytP9AAoJEAVLu599gGRCjDwQAKo+vaP5NFRiBZ263xUhOJBS
mtw470IGGdMmKJgbi2t0HkFJSmhwKgUd9u12hvyp8EwSLT3seUd8mFs+zKYejrN3
1khqFKeqUGhwblRe0jzrO5qpMDzL8z2dHKwCpbHLmMkChmJ+r0d8oRr2arPRncb4
P9vRVkl6mjxvnSiNgzN9ZYeD7aM0be1KXXM2DolxcLbGYV/EHOUG7qr2LJCSY8bb
B9NKsYrqqZ+l53BenfRYbNpCYJQxDYfZa/rIy/Tg/Oo2J00e3Q49txBcWXgT5GHr
S77PL8l1oac7keTcAqRXV8Fxcop2ZkHlDlCwgQHK2qUeDg/1IkJrzpgOk0z09ll/
rXRB+fnJwtkGU1WB1lsTll0o5v1dYegp7f4AsLG0/v8qUFf70kgLNs34G+ETlc5d
EZkm7ckNb0BFTCtpAhz16vLImYbVkI/Onq5eJMHzeo7Q6tr51bk1JMtqfPqxpiGj
zuiT7SENwVhH3fgon/J1lWfOSTPNed5EYENf2djO0eYOzTmfaNgMDpIrsBDodzCs
lNU6KsY57OUI5lmRptO8MYeyftVev+6wPzCr+TfXQIbdaPKcPwdMOnVVlntuJkFy
oaEJiLTf/PDzSeu2rUUG5KCi30aoXujJNX2KNUlwFCXxwV1DQe1l+6jyt6/iggbs
wgBkCXku2rhGXJqdmjmV
=qo6r
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.