Processed: reassign 633057 to lintian
Processing commands for cont...@bugs.debian.org: > # Let's use a version that actually exists... > reassign 633057 lintian 2.5.1 Bug #633057 [src:lintian] lintian: a central place to list Python versions Bug reassigned from package 'src:lintian' to 'lintian'. Bug No longer marked as found in versions lintian/2.5.2. Bug #633057 [lintian] lintian: a central place to list Python versions Bug Marked as found in versions lintian/2.5.1. > thanks Stopping processing here. Please contact me if you need assistance. -- 633057: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633057 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131008075119788.transcr...@bugs.debian.org
Bug#633044: [checks/fields] please add python3-dev to $PYTHON_DEV
Package: lintian
Version: 2.5.1
Severity: minor
Tags: patch
Please see the attached patch.
--
Jakub Wilk
diff --git a/checks/fields b/checks/fields
--- a/checks/fields
+++ b/checks/fields
@@ -172,7 +172,7 @@
# Python development packages that are used almost always just for building
# architecture-dependent modules. Used to check for unnecessary build
# dependencies for architecture-independent source packages.
-our $PYTHON_DEV = join(' | ', qw(python-dev python-all-dev python3-all-dev),
+our $PYTHON_DEV = join(' | ', qw(python-dev python-all-dev python3-dev python3-all-dev),
map { "python$_-dev" } qw(2.4 2.5 2.6 3 3.1));
our $PERL_CORE_PROVIDES = Lintian::Data->new('fields/perl-provides', '\s+');
Bug#633057: lintian: a central place to list Python versions
Source: lintian Version: 2.5.2 Severity: wishlist The are currently (at least?) 2 places where lintian lists Python versions: checks/rules ($PYTHON2X_DEPEND, $PYTHON3X_DEPEND) and checks/fields ($PYTHON_DEV). Theses lists can quickly get out of sync and out of date. It'd nice if lintian could have a central place (somewhere in /u/s/lintian/data/?) to list Python version. Also, we should decide *which* versions we are actually interested in? All currently supported in unstable? All currently existing in unstable? Maybe all supported either in unstable or stable? (debian-python@ CCed.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110707231517.ga4...@jwilk.net
[SCM] Debian package checker branch, master, updated. 2.5.1-40-g4a7b371
The following commit has been merged in the master branch:
commit 4a7b37126a128c3494106aefd6bef935f50a31d7
Author: Niels Thykier
Date: Fri Jul 8 01:19:19 2011 +0200
Updated the Lintian User Manual
diff --git a/debian/changelog b/debian/changelog
index 0089b71..99c3b1f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -97,6 +97,9 @@ lintian (2.5.2) UNRELEASED; urgency=low
* doc/lintian.xml:
+ [NT] Added information about the new Vendor profiles.
++ [NT] Improved various parts of the User Manual. Especially
+ mention that Lintian can be run on changes files and this
+ processes all packages related to the changes file.
* frontend/{lintian,lintian-info}:
+ [NT] Added profile support (new option --profile), please
diff --git a/doc/lintian.xml b/doc/lintian.xml
index 94d2965..8468e64 100644
--- a/doc/lintian.xml
+++ b/doc/lintian.xml
@@ -279,13 +279,26 @@
the lintian Debian
package.
+
+Alternatively you can checkout Lintian from the source
+repository and use that directly. By setting LINTIAN_ROOT (or
+using the --root option) lintian can be run from the source
+directory as if it had been installed on your system.
+
+
+The only known caveat of using Lintian from the source
+directory is that Lintian requires a C.UTF-8 (or en_US.UTF-8)
+locale to correctly process some files.
+The lintian Debian
+package will set up this locale during installation.
+
Running lintian
-After that, you can run Lintian over any Debian binary, udeb
-or source packages like this:
+After that, you can run Lintian on a changes file or any
+Debian binary, udeb or source packages like this:
$ lintian libc5_5.4.38-1.deb
@@ -299,16 +312,28 @@ E: libc5: shlib-missing-in-control-file libgnumalloc
usr/lib/libgnumalloc.so.5.4
$
-As you can see, Lintian uses a special format for all its
-error and warning messages. With that, its very easy to write
-other programs which run Lintian and interpret the displayed
-messages.
+Please note that some checks are cross-package checks and can
+only be (accurately) performed if the binary packages and the
+source are processed together. If Lintian is passed a changes
+file, it will attempt to process all packages listed in the
+changes file.
+
+
+Lintian supports a number of command line options, which are
+documented in the manpage of lintian(1). Some of the options
+may appear in the lintianrc file (without the leading dashes)
+in Lintian 2.5.1 (or newer).
Lintian Tags
+Lintian uses a special format for all its error and warning
+messages. With that it is very easy to write other programs
+which run Lintian and interpret the displayed messages.
+
+
The first character of each line indicates the type of
message. Currently, the following types are supported:
@@ -472,12 +497,19 @@ $
sure the problem is not actually a bug in Lintian or an error in the
author's
reading of policy. Please do not override bugs in lintian, they should
rather
be fixed than overridden.
+
+
Once it has been decided that an override is needed, you can easily
add one by
supplying an overrides file. If the override is for a binary or udeb
package, you have to place it at
/usr/share/lintian/overrides/
-inside the package. If the override is for a source package,
-you have to place it
+inside the package. The tool dh_lintian
+from the Debian
+package debhelper may
+be useful for this purpose.
+
+
+If the override is for a source package, you have to place it
at debian/source/lintian-overrides
or debian/source.lintian-overrides (the
former path is preferred). With that, Lintian will know about
--
Debian package checker
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qexuh-0005zy...@vasks.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.1-39-ga19ac5b
The following commit has been merged in the master branch:
commit a19ac5b7357423776120ab9339de1db4685db3cf
Author: Niels Thykier
Date: Tue Jun 28 11:55:52 2011 +0200
Replaced unpack-srcpkg-l1 with an extended coll/index
Moved the indexing code from unpack-srcpkg-l1 to coll/index with
a few changes to handle multiple orig-tarballs.
Note: Symlink of source pkg parts has been moved to Lab::Package for
when it creates the entry. Creating a separate coll for that seemed
like overkill.
diff --git a/collection/index b/collection/index
index eedc12a..00f8263 100755
--- a/collection/index
+++ b/collection/index
@@ -29,6 +29,8 @@ use vars qw($verbose);
# import perl libraries
use lib "$ENV{'LINTIAN_ROOT'}/lib";
+use Cwd();
+use File::Spec;
use Util;
use Lintian::Command qw(spawn reap);
@@ -36,37 +38,189 @@ use Lintian::Command qw(spawn reap);
my $pkg = shift;
my $type = shift;
-my (@jobs, $job);
+unlink 'index' or fail "Could not unlink index: $!" if -e 'index' && -s
'index';
+unlink 'index-errors' or fail "Could not unlink index-errors: $!" if -e
'index-errors' && -s 'index-errors';
-foreach my $file qw(index index-errors index-owner-id) {
-unlink $file or fail "$file: $!" if -f $file;
+if ($type ne 'source') {
+index_deb();
+} else {
+index_src();
}
-$job = { fail => 'error',
- out => 'index',
- err => 'index-errors' };
-push @jobs, $job;
-# (replaces dpkg-deb -c)
-# create index file for package
-spawn($job,
- ['dpkg-deb', '--fsys-tarfile', 'deb' ],
- '|', ['tar', 'tfv', '-'],
- '|', ['sed', '-e', 's/^h/-/'],
- '|', ['sort', '-k', '6'], '&');
-
-$job = { fail => 'error',
- out => 'index-owner-id',
- err => '/dev/null' };
-push @jobs, $job;
-# (replaces dpkg-deb -c)
-# create index file for package with owner IDs instead of names
-spawn($job,
- ['dpkg-deb', '--fsys-tarfile', 'deb' ],
- '|', ['tar', '--numeric-owner', '-tvf', '-'],
- '|', ['sed', '-e', 's/^h/-/'],
- '|', ['sort', '-k', '6'], '&');
-
-reap(@jobs);
-undef @jobs;
-
exit 0;
+
+# returns all (orig) tarballs.
+sub gather_tarballs {
+my $file = Cwd::realpath('dsc');
+my $dir;
+my $data;
+my $version;
+my @tarballs;
+my $base;
+my $baserev;
+fail "Cannot resolve \"dsc\" link for $pkg or it does not point to a
file.\n" unless $file and -e $file;
+(undef, $dir, undef) = File::Spec->splitpath($file);
+$data = get_dsc_info($file) or fail "Could not parse dsc file for $pkg.\n";
+# Version handling is based on Dpkg::Version::parseversion.
+$version = $data->{'version'};
+if ($version =~ /:/) {
+$version =~ s/^(?:\d+):(.+)/$1/ or fail("bad version number
'$version'");
+}
+$baserev = $data->{'source'} . '_' . $version;
+$version =~ s/(.+)-(.*)$/$1/;
+$base = $data->{'source'} . '_' . $version;
+for my $fs (split(/\n/,$data->{'files'})) {
+$fs =~ s/^\s*//;
+next if $fs eq '';
+my @t = split(/\s+/o,$fs);
+next if ($t[2] =~ m,/,);
+# Look for $pkg_$version.orig(-$comp)?.tar.$ext (non-native)
+# or $pkg_$version.tar.$ext (native)
+# - This deliberately does not look for the debian packaging
+#even when this would be a tarball.
+if ($t[2] =~
/^(?:\Q$base\E\.orig(?:-(.*))?|\Q$baserev\E)\.tar\.(?:gz|bz2|lzma|xz)$/) {
+push @tarballs, [$t[2], $1//''];
+}
+}
+fail('could not find the source tarball') unless @tarballs;
+return @tarballs;
+}
+
+# Creates an index for the source package
+sub index_src {
+my @tarballs = gather_tarballs();
+my @result;
+foreach my $tardata (@tarballs) {
+ my ($tarball, $compname) = @$tardata;
+ my @index;
+# Collect a list of the files in the source package. tar currently
doesn't
+# automatically recognize LZMA / XZ, so we need to add the option
where it's
+# needed. Change hard link status (h) to regular files and remove a
leading
+# ./ prefix on filenames while we're reading the tar output. We
intentionally
+# don't parallelize this job because we need to use the output below.
+my @tar_options = ('-tvf');
+my $last = '';
+my $collect;
+if ($tarball =~ /\.(lzma|xz)\z/) {
+unshift(@tar_options, "--$1");
+}
+$collect = sub {
+my @lines = map { split "\n" } @_;
+if ($last ne '') {
+$lines[0] = $last . $lines[0];
+}
+if ($_[-1] !~ /\n\z/) {
+$last = pop @lines;
+} else {
+$last = '';
+}
+for my $line (@lines) {
+$line =~ s/^h/-/;
+if ($line and $line !~ m,^(?:\S+\s+){5}\./$,) {
+push(@index, $line . "\n");
+}
+}
+}; # End $collect = sub;
+spawn({ fail =>
[SCM] Debian package checker branch, master, updated. 2.5.1-39-ga19ac5b
The following commit has been merged in the master branch: commit 5c29ca0c0e0a6811757128c9db7391b778390a75 Author: Niels Thykier Date: Thu Jul 7 23:25:31 2011 +0200 Added B-D on cdbs for a test and fixed a legacy test diff --git a/debian/changelog b/debian/changelog index 80ef749..a74bb1b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -84,6 +84,8 @@ lintian (2.5.2) UNRELEASED; urgency=low + [NT] Bumped debhelper version to 8.1.0 due to the build-arch and build-indep targets. Thanks to Mark Hymers for the heads up and a patch. (Closes: #632550) ++ [NT] Added Build-Depends on cdbs, it is needed for some of the + tests. * debian/lintian.install: + [NT] Added the profiles directory. * debian/rules: diff --git a/debian/control b/debian/control index c67a40a..2ffa6fa 100644 --- a/debian/control +++ b/debian/control @@ -12,6 +12,7 @@ Uploaders: Josip Rodin , Raphael Geissert , Niels Thykier Build-Depends: binutils, + cdbs, debhelper (>= 8.1.0~), default-jdk, diffstat, diff --git a/testset/tags.filenames b/testset/tags.filenames index c00837a..12a1f9e 100644 --- a/testset/tags.filenames +++ b/testset/tags.filenames @@ -145,7 +145,7 @@ W: more-filename-games: binary-without-manpage usr/bin/another-test-game W: more-filename-games: binary-without-manpage usr/games/yet-another-test-game W: more-filename-games: package-section-games-but-has-usr-bin X: filenames: duplicate-files usr/share/doc/filenames/.DS_Store usr/share/doc/filenames/._NEWS.Debian usr/share/doc/filenames/Thumbs.db usr/share/doc/filenames/link-one -X: filenames: duplicate-files usr/share/doc/filenames/NEWS.Debian usr/share/doc/filenames/README.macosx usr/share/doc/filenames/examples/__init__.py usr/share/doc/filenames/examples/very_interesting_example +X: filenames: duplicate-files usr/share/doc/filenames/NEWS.Debian usr/share/doc/filenames/README.macosx usr/share/doc/filenames/examples/very_interesting_example X: filenames: package-contains-broken-symlink usr/lib/filenames/symlink1ok ../../share/symlink X: filenames: package-contains-broken-symlink usr/lib/filenames/symlink1wrong ../../../etc/symlink X: filenames: package-contains-broken-symlink usr/lib/filenames/symlink2ok etc/symlink -- Debian package checker -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qewmc-0001qx...@vasks.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.1-39-ga19ac5b
The following commit has been merged in the master branch:
commit 9045e68c8bffd1e71451412a78654271b2dbf5a8
Author: Niels Thykier
Date: Thu Jul 7 23:51:23 2011 +0200
Corrected a typo in the changelog
diff --git a/debian/changelog b/debian/changelog
index a74bb1b..7f31475 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -23,7 +23,7 @@ lintian (2.5.2) UNRELEASED; urgency=low
some license texts. Thanks to Charles Plessy for the
report. (Closes: #631674)
* checks/deb-format{,.desc}:
-+ [NT] Allow data.tar.xz as the second member. Thanks to
++ [NT] Allow data.tar.xz as the third member. Thanks to
Ansgar Burchardt for the report and patch.
(Closes: #632556)
* checks/debhelper:
--
Debian package checker
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qewmf-0001rq...@vasks.debian.org
Re: Lintian as a static analysis framework
On Thu, Jul 7, 2011 at 6:24 PM, Stefano Zacchiroli wrote: > - the reborn of a sources.debian.org service (sort of browsable / > highlighted/ searchable Debian sources at your fingertips on the web) Is there any info about this? Last year Noel was working on such a project also: http://wiki.debian.org/source.debian.org At one point there was source.debian.net running OpenGrok, a very nice Java-based source code indexer. > - Coccinelle [1] runs on the whole of Debian sources, meant to be > integrated with DACA [2] Very nice. > I've ended up cooking up my own code for the above (not all is done > yet), but there clearly a good part of it that could be factored out > (and done better). Do you think the framework you're imagining at this > point could help with any or all of the above? If yes, I'll be happy to > provide testing and/or comment on whether the design would fit the need > of the above use cases. I'm thinking yes but I'm not that familiar with lintian internals so I will leave that to them. > FWIW, I believe many other wannabe entrants in DACA would benefit from > the addressing of similar use cases. Yeah, DACA was my initial thought here. Why not have a source-has-warnings-from-cppcheck lintian warning and logs for those on lintian.d.o. Same goes for lots of the other existing checkers listed in the mentors metrics[1] ideas; jpeginfo --check, pngcheck, mp3diags, desktop-file-validate, fontlint, gettext-lint etc. Of course, the addition of these many external checkers will mean more CPU and I/O time. I guess the lintian vendor stuff could be leveraged to have a set of profiles for different amounts of checking. In addition this could mean that a more distributed approach to processing packages for lintian.d.o would be better. Looking at the metrics again, I'm also thinking about debexpo, Mole, puiparts and that some consolidation of efforts would be nice. With a few feature additions, maybe it would even be possible to merge rpmlint one day ;) 1. http://wiki.debian.org/DebianMentorsNet#Metrics -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HXEhOnqt0Arwe5DhC3ctXXVvbOFbfEbS0q04ooWJMV=q...@mail.gmail.com
Re: Lintian as a static analysis framework
On Thu, Jul 07, 2011 at 12:00:38PM +0200, Niels Thykier wrote:
> Yesterday in #debian-qa, I chatted with Paul Wise and the idea came up
> that Lintian should be a framework that others could use as a basis for
> their own analysis - particularly when these analysis would conflict
> with some of the Lintian design goals (namely we try to be independent
> of the system state).
Thanks for sharing this with other lists.
I don't know the current (internal) APIs you mention, but I feel like
sharing a use case that might benefit from the framework refactoring you
propose. It's a use case I've encountered while setting up two things at
once (none of which is finished yet...):
- the reborn of a sources.debian.org service (sort of browsable /
highlighted/ searchable Debian sources at your fingertips on the web)
- Coccinelle [1] runs on the whole of Debian sources, meant to be
integrated with DACA [2]
[1] http://coccinelle.lip6.fr/
[2] http://qa.debian.org/daca/
To achieve the above two goals, I need to keep in sync a Debian (source)
mirror with a place where I've all sources unpacked in versioned
directories. Additions/removals to the mirror should be reflected to the
unpacked source storage. I'd also like to be flexible in adding/removing
suites and archive areas to the source mirror, as well as be easily able
to re-extract everything from source. So much for the extraction part.
Then I need an easy way to access all (unpacked) source packages I have,
query their package metadata, find their root directory and run my
analysis tool of choice on the source package.
Finally there is also a database part, where I'd like to storage the
result of the analysis tool and keep all the history of it.
I've ended up cooking up my own code for the above (not all is done
yet), but there clearly a good part of it that could be factored out
(and done better). Do you think the framework you're imagining at this
point could help with any or all of the above? If yes, I'll be happy to
provide testing and/or comment on whether the design would fit the need
of the above use cases.
FWIW, I believe many other wannabe entrants in DACA would benefit from
the addressing of similar use cases.
Thanks for sharing and for thinking about this!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: lintian and Debian derivatives
On Thu, Jul 7, 2011 at 11:18 AM, Neil Williams wrote: > Lintian requires a lot of resources if it's to be run automatically > against an entire distribution. Yeah. Also there is quite a bit of scope for expanding the range of tests lintian performs, by running external checkers like cppcheck, pngcheck etc, which can only make lintian runs more time consuming. Neils posted a thread about that just now. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EFAQBURqdd912Jc=y5kczxv8ywa0qs0x_r_0yrw2n...@mail.gmail.com
Lintian as a static analysis framework
Hi
Yesterday in #debian-qa, I chatted with Paul Wise and the idea came up
that Lintian should be a framework that others could use as a basis for
their own analysis - particularly when these analysis would conflict
with some of the Lintian design goals (namely we try to be independent
of the system state).
When I write "Lintian should be a framework", feel free to read it as
"refactor a framework out of Lintian, on which Lintian will depend and
the framework will have a separate name".
Occasionally I have found myself considering to write some tool to check
for something that would require (e.g.) a Packages file[1] only to stop
because I need to (re-)write a package extractor, a dsc or d/control
parser, two of Lintian's collections and then my analysis code on top of
that.
Of course with my knowledge of Lintian's internals I could still soup
together some code that would allow me to re-use (the parts of) Lintian
(I need), but as implied - it would not be pretty.
A(nother) personal thorn in my side would be #262783; in my ideal world
this ought fairly simple, but in reality it is very complex. Mostly
because the frontend actually glues the Lab together with the
collections and the checks. The frontend also peeks deep into the
internal parts of the lab structure (to test for and mark collections as
finished). To me this is a sign that our backend needs more work.
To be honest I have even considered factoring our (new) test suite code
so packaging tools like debhelper and javatools can (ab)use it for their
own test suite.
The idea of template packages where you only have to mess with a bare
minimum to get a package is nice and I could have used that for
javatools to catch regressions a number of times now, but I do not feel
like re-inventing the wheel either.
On the other hand, I know it can be difficult to settle and maintain a
public API. As far as I can tell, we have currently only officially
committed ourselves to the frontends and the profiles + the (names of)
the tags, checks and the collections. Everything else we can basically
break and smash as we much like as long as we fix it before we hit
release (which I admit is nice from a developer's point of view).
That being said, I could see us commit to a liblintian-perl[2] that
would for starters provide things like Lab, Lab::Package, the
collections and Lintian::Collect{,::Binary,::Source,::Changes} (possibly
moving Lab + Lab::Package under the Lintian:: prefix first).
As we mature other things (or people request it) we could migrate more
and more of lib/ into liblintian-perl.
As for the test suite code, I would mature it a bit more and then
refactor it into an external package to avoid circular
build-dependencies between Lintian and javatools (javahelper) if possible.
Obviously, these changes would very likely fall under the "Hard
projects" listed on [3], but I think we would do ourselves and the
Debian project a favour in the long run by doing this.
~Niels
[1] Or some other data that we in Lintian can never rely on being
present and up to date.
[2] Care must be taken here to ensure we keep the "git clone, hack, run"
property if we install the code in liblintian-perl under /usr/share/perl5.
[3] http://wiki.debian.org/Teams/Lintian
--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e1583c6.3090...@thykier.net
Re: lintian and Debian derivatives
On Thu, 07 Jul 2011 00:25:59 +0200 Paul Wise wrote: > As a member of the Debian derivatives front desk (CCed) and initiator of > the derivatives census, which aims to make derivatives more visible to > Debian, I figured I should update lintian folks on the state of lintian > development and usage in Debian derivatives. Just a note, Emdebian is involved in lintian testing for Emdebian packages, via the new lintian profile support (based on DEB_VENDOR), but as the current Emdebian release (Grip) is binary-compatible with Debian, the emphasis is on ensuring that the processed packages comply with the Emdebian Policy changes from Debian Policy. (Specifically, allow the removal of manpages and other files which lintian would otherwise output as missing, allow compression where Debian does not, etc.) Once MultiArch is in place with cross-building support, things will change and Emdebian will again start using lintian in earnest. Quite how and where the lintian tests are run is largely a problem of resources. > In addition, there is one derivative that I know of that has current and > public lintian web pages, but I guess that one is well known by lintian > maintainers since I guess it is run by Russ. It is a shame that lintian > pages aren't more widespread within our derivatives. I guess some use it > on the packages during their build process but I wonder how we could > encourage them to use it more, anyone have any thoughts? Lintian requires a lot of resources if it's to be run automatically against an entire distribution. Emdebian will look at lintian reports for cross-built stuff but that's only because that is likely to be limited to less than a thousand source packages. Even then, I'm expecting the full lintian test to take almost as long as it currently takes to process the daily updates to Emdebian Grip. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp6I4ZpEPdo1.pgp Description: PGP signature
Re: lintian and Debian derivatives
On 2011-07-07 09:10, Paul Wise wrote: > On Thu, Jul 7, 2011 at 12:49 AM, Geoffrey Thomas wrote: > >> [...] > Hi, >> In terms of making Lintian useful for derivatives, I think the biggest >> feature we'd like is having a way to suppress Lintian checks during the >> build process for an entire origin of packages (defined somehow...). > > Probably this will be useful to you: > > http://wiki.debian.org/Lintian/Spec/VendorCustomization > > The work on this is in progress, so I would suggest you check it out > as soon as possible. > > If you have any suggestions on how it works, now is the time to make them. > The implementation has been merged into the master branch already, but we have not released yet so we can still take suggestions without breaking any "official stable" API. :) Anyhow, basically Lintian will do the right thing if the debathena has / provides two things: A dpkg origin file and a Lintian vendor profile. In the absence of a dpkg-origin file, you can use LINTIAN_PROFILE in the config file (which works as long as the user does not have their own and forget to copy that part). The wiki page /should/ be up to date, but if there are disagreements between the Lintian User manual (doc/lintian.xml in the source) and the wiki page, let me know so I can fix it. ~Niels -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1561af.10...@thykier.net
Re: lintian and Debian derivatives
On Thu, Jul 7, 2011 at 12:49 AM, Geoffrey Thomas wrote: > We are the only one? I'm proud :-) We set that up about a year ago because > why not, but in practice, we've more been using Lintian output from the > package build process (debuild/sbuild) than the page, and making sure there > are no regressions and no unexpected warnings on new packages. Cool :) > In terms of making Lintian useful for derivatives, I think the biggest > feature we'd like is having a way to suppress Lintian checks during the > build process for an entire origin of packages (defined somehow...). Probably this will be useful to you: http://wiki.debian.org/Lintian/Spec/VendorCustomization The work on this is in progress, so I would suggest you check it out as soon as possible. If you have any suggestions on how it works, now is the time to make them. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EC0qQ8C4eBaWzbwXVw-azg3XjDF2DK==ccxhjgeja...@mail.gmail.com
