Re: Status on Lintian 2.5.0~rc3
Hi Niels,
On Sat, Apr 09, 2011 at 02:36:17PM +0200, Niels Thykier wrote:
> I thought I would bring a little update on the progress on Lintian
> 2.5.0~rc3. I have CC'ed Steve Langasek and Vincent Fourmond because I
> last I heard from you, you were working on patches for bugs I am
> considering for the 2.5.0~rc3 release (and I was not sure if you were
> subscribed).
> Status/summery
> ==
> Since my last update [LU], I have fixed #618587 (armhf support), #621667
> (Add S-V 3.9.2), #621658 (add/use --dump-logs in tests[1]),
> #621681 (disable pkgbinarymangler during tests[2]) and #621667 (add
> spelling mistakes/corrections). I also fixed the uninitialized variable
> errors mentioned in #621006.
>
> On my TODO list I still have the merge of infra-513663 into master
> (scheduled for Tuesday), inclusion of more java checks (#600829, waiting
> for tests) and some multi-arch related checks (bug/patch no yet, waiting
> for vorlon). I may also include #620120 (confusion about dash
> essentialness) in 2.5.0~rc3.
Sorry for the delays getting this to you. The attached patches take care of
the most critical multiarch checks. Along the way I found that
data/binaries/multiarch was being used to incorrectly suppress warnings
about files forbidden by policy, so the first patch removes this wrong file;
and that data/files/triplets is already used for per-architecture filesystem
paths, so I've updated this to use the final multiarch paths based on
DEB_HOST_MULTIARCH instead of DEB_HOST_GNU_TYPE (second patch).
The third patch in the series adds the new check for multiarch-support, the
one we need in place to make sure developers aren't breaking the world as
they upload libraries. I strongly believe this should be an archive check,
fwiw.
The fourth patch fixes up the test suite for binaries-multiarch - since
i486-linux-gnu is no longer treated as a multiarch directory (because it
isn't), the test case fails to trigger the error. We may want an additional
test case later to warn about /usr/lib/i486-linux-gnu in general, but that's
a lower priority.
I'm sorry to say I haven't included a test suite change yet to go with patch
#3. I'll work on that, but can't promise when I'll have it done.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
From 0ec0dea6f448387b35b097d91ced04cbda0e266e Mon Sep 17 00:00:00 2001
From: Steve Langasek
Date: Mon, 18 Apr 2011 01:07:14 -0700
Subject: [PATCH 1/4] Drop wrong checks for multiarch directories
Architecture: all packages and packages of a different architecture are not
allowed to install libraries to the multiarch directories. Drop these wrong
exclusions.
---
checks/binaries | 20
data/binaries/multiarch | 18 --
debian/changelog|4
3 files changed, 8 insertions(+), 34 deletions(-)
delete mode 100644 data/binaries/multiarch
diff --git a/checks/binaries b/checks/binaries
index eda994a..626934d 100644
--- a/checks/binaries
+++ b/checks/binaries
@@ -115,8 +115,6 @@ our %EMBEDDED_LIBRARIES = (
'libpcap' => qr'(?:pcap_activate: The "any" device isn\'t supported|corrupted frame on kernel ring mac offset)',
);
-our $MULTIARCH;
-
sub run {
my $pkg = shift;
@@ -239,16 +237,9 @@ foreach my $file (@{$info->sorted_file_info}) {
# binary or object file?
next unless ($fileinfo =~ m/^[^,]*\bELF\b/) or ($fileinfo =~ m/\bcurrent ar archive\b/);
-# Warn about Architecture: all packages that contain shared libraries, but
-# only if those libraries aren't installed in a multiarch directory. The
-# package may be a support package for cross-compiles.
+# Warn about Architecture: all packages that contain shared libraries.
if ($arch eq 'all') {
- my ($arch_path) = ($file =~ m,^(?:usr/)?lib/([^/]+)/,);
- $MULTIARCH = Lintian::Data->new('binaries/multiarch')
- unless defined($MULTIARCH);
- unless ($arch_path and $MULTIARCH->known($arch_path)) {
- tag 'arch-independent-package-contains-binary-or-object', $file;
- }
+ tag 'arch-independent-package-contains-binary-or-object', $file;
}
# ELF?
@@ -263,7 +254,7 @@ foreach my $file (@{$info->sorted_file_info}) {
}
if ($arch ne 'all' and $fileinfo !~ m/$ARCH_REGEX{$arch}/) {
- if ($file =~ m,(?:^|/)lib(\d{2})/, or $file =~ m,^emul/ia(\d{2}),) {
+ if ($file =~ m,(?:^|/)lib(\d{2})/, or $file =~ m,^emul/ia(\d{2}),) {
tag 'binary-from-other-architecture', $file
unless ($fileinfo =~ m/$ARCH_REGEX{$1}/);
} elsif ($arch eq 'amd64' and $fileinfo =~ m/$ARCH_REGEX{i386}/) {
@@ -273,10 +264,7 @@ foreach my $file (@{$info->sorted_file_info}) {
and $file =~ m,^lib/modules/,) {
# Allow amd64 kernel modules to be installed on i386.
} else {
-
Re: Vendor-based customization of Lintian (or profiles)
On Tue, Apr 19, 2011 at 06:14:25PM +0200, Niels Thykier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi > > Considering that #513663 will be closed in 2.5.0~rc3, I figured it was > time to start a new branch. XD w00t! > I was considering to do either Vendor-based customization or support > third party checks (e.g. Lintian "extra"), as the subject suggests I > think I will start with Vendor-based Lintian. > However if you think third party checks should be given priority, let > me know - this decision is not set in stone. :) I strongly feel vendor based customizations should be the Next Big Thing. I started a fork of lintian in Maemo, called maemian, but it quickly bogged down due to the complexities you mention in Ubuntu. The point is that I think this would be welcome amongst derivatives and improve the quality of derivative package and ultimately Debian. I'm very glad that you're looking into doing this Niels - thank you. And thank you for your work on lintian. To be honest, I've rarely seen more productive programmers than yourself! Thanks! Jeremiah -- 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/20110419210251.GA7526@localhost
Processed: submitter 623390
Processing commands for cont...@bugs.debian.org: > submitter 623390 vinc4...@gmail.com Bug #623390 [lintian] lintian: Please add Ruby-Versions to known binary/dsc fields Changed Bug submitter to 'vinc4...@gmail.com' from 'Niels Thykier ' > thanks Stopping processing here. Please contact me if you need assistance. -- 623390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623390 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.130324285120644.transcr...@bugs.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-148-g0cd4f45
The following commit has been merged in the master branch:
commit 0cd4f455b7bfb754f372472b20b94b0c94bbe3da
Author: Niels Thykier
Date: Tue Apr 19 22:00:46 2011 +0200
Revert "Added breaks on emdebian-crush and xdeb due to unpack removal"
This reverts commit c577bd2316d6ff16af598ad508998dd1d53571f7.
Per request of Neil Williams for emdebian-crush and also made a
compelling argument for removing it for xdeb.
diff --git a/debian/changelog b/debian/changelog
index 963e384..3012d31 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -90,9 +90,6 @@ lintian (2.5.0~rc3) UNRELEASED; urgency=low
+ [NT] Bumped Standards-Version to 3.9.2.
+ [NT] Updated Build-Depends for debiandoc -> docbook change of
the manual.
-+ [NT] Added a breaks on emdebian-crush and xdeb, since their
- checks will most likely not work without bumping their
- Needs-Info for the checks.
* debian/{docs,rules}:
+ [NT] Updated to use/install docbook instead of debiandoc.
diff --git a/debian/control b/debian/control
index a83d2d4..5bd9be0 100644
--- a/debian/control
+++ b/debian/control
@@ -71,7 +71,6 @@ Depends: ${misc:Depends},
perl,
unzip
Suggests: binutils-multiarch, libtext-template-perl, man-db (>= 2.5.1-1)
-Breaks: emdebian-crush (<= 2.2.15), xdeb (<= 0.6.4)
Description: Debian package checker
Lintian dissects Debian packages and reports bugs and policy
violations. It contains automated checks for many aspects of Debian
--
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/e1qch90-0008fi...@alioth.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-148-g0cd4f45
The following commit has been merged in the master branch:
commit ab6c18ad620ad9c8f6129d603a5c89556f8b827d
Author: Niels Thykier
Date: Tue Apr 19 22:00:18 2011 +0200
Revert "Revert "Fixed test failure with d/changelog""
This reverts commit 5179c8040fca90825dd9397ce201a524cbd5b3d9.
Reverted the wrong commit
diff --git a/debian/changelog b/debian/changelog
index 9a605ba..963e384 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -39,7 +39,7 @@ lintian (2.5.0~rc3) UNRELEASED; urgency=low
+ [NT] Added dir-or-file-in-run tag. (Closes: #623031)
* checks/java{,.desc}:
+ [NT] Added file based on patches submitted by Vicent Fourmond.
- - This new file checks for jar files in weird locations.
+ This new file checks for jar files in weird locations.
(Closes: #620829, #575447)
* checks/manpages:
+ [NT] Fixed false-positive binary-without-manpage when the
--
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/e1qch8z-0008ds...@alioth.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-146-g5179c80
The following commit has been merged in the master branch:
commit 5179c8040fca90825dd9397ce201a524cbd5b3d9
Author: Niels Thykier
Date: Tue Apr 19 21:57:51 2011 +0200
Revert "Fixed test failure with d/changelog"
This reverts commit 7e3e4fafa130ee7ea0c1445491aedf21c935a9e7.
Per request of Neil Williams for emdebian-crush and also made a
compelling argument for removing it for xdeb.
diff --git a/debian/changelog b/debian/changelog
index 963e384..9a605ba 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -39,7 +39,7 @@ lintian (2.5.0~rc3) UNRELEASED; urgency=low
+ [NT] Added dir-or-file-in-run tag. (Closes: #623031)
* checks/java{,.desc}:
+ [NT] Added file based on patches submitted by Vicent Fourmond.
- This new file checks for jar files in weird locations.
+ - This new file checks for jar files in weird locations.
(Closes: #620829, #575447)
* checks/manpages:
+ [NT] Fixed false-positive binary-without-manpage when the
--
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/e1qch7h-00078y...@alioth.debian.org
Bug#623390: lintian: Please add Ruby-Versions to known binary/dsc fields
Package: lintian Severity: wishlist On 2011-04-19 20:32, Vincent Carmona wrote: > 2011/4/9 Vincent Carmona : >> Hi lintian team. >> >> Ruby packaging is changing (see >> http://wiki.debian.org/Teams/Ruby/RubyInWheezy). >> When checking my dsc file lintian return a warning: >> ruby-globalhotkeys source: unknown-field-in-dsc ruby-versions >> >> In d/control I have XS-Ruby-Versions and XB-Ruby-Versions defined. >> >> They should be defined for all ruby packages in wheezy. Could you add >> an exception to supress warnings ? >> >> -- >> Vincent Carmona >> > > I forget to say that I am not subscribed to this mailling list. Can > you please cc me ? > I do not see any response yet. If I am wrong please correct me. > > I do not see a reply to it yet either, so I am opening a bug for 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/4dade41a.6080...@thykier.net
Re: Vendor-based customization of Lintian (or profiles)
On Tue, 19 Apr 2011 21:02:27 +0200 Niels Thykier wrote: > > Emdebian tried this and came up against a few hidden assumptions in > > lintian which we discussed with the lintian maintainers at the time. We > > experimented with an emdebian checks file and desc file: > > > > http://packages.debian.org/sid/all/emdebian-crush/filelist > > > > If this proposal completes the final stage of that process, I will be > > v.happy. :-) > > Do you have a link to that debate; unfortunately I believe it was before > my involvement with Lintian, so I do not believe I have seen it (unless > it is covered in the DC10 notes from the BoF). Not really. I did describe some of the results to the Emdebian folks: http://lists.debian.org/debian-embedded/2008/04/msg3.html http://lists.debian.org/debian-embedded/2009/12/msg00032.html The other discussions with Russ were mostly direct email and/or discussions at DebConf9. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpKvBnkJLj0z.pgp Description: PGP signature
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-145-gc577bd2
The following commit has been merged in the master branch:
commit c577bd2316d6ff16af598ad508998dd1d53571f7
Author: Niels Thykier
Date: Tue Apr 19 21:21:08 2011 +0200
Added breaks on emdebian-crush and xdeb due to unpack removal
We removed some scripts in unpack/ so old checks relying on
(e.g.) fields being present will fail in wierd ways if their
Needs-Info are not updated.
diff --git a/debian/changelog b/debian/changelog
index 3012d31..963e384 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -90,6 +90,9 @@ lintian (2.5.0~rc3) UNRELEASED; urgency=low
+ [NT] Bumped Standards-Version to 3.9.2.
+ [NT] Updated Build-Depends for debiandoc -> docbook change of
the manual.
++ [NT] Added a breaks on emdebian-crush and xdeb, since their
+ checks will most likely not work without bumping their
+ Needs-Info for the checks.
* debian/{docs,rules}:
+ [NT] Updated to use/install docbook instead of debiandoc.
diff --git a/debian/control b/debian/control
index 5bd9be0..a83d2d4 100644
--- a/debian/control
+++ b/debian/control
@@ -71,6 +71,7 @@ Depends: ${misc:Depends},
perl,
unzip
Suggests: binutils-multiarch, libtext-template-perl, man-db (>= 2.5.1-1)
+Breaks: emdebian-crush (<= 2.2.15), xdeb (<= 0.6.4)
Description: Debian package checker
Lintian dissects Debian packages and reports bugs and policy
violations. It contains automated checks for many aspects of Debian
--
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/e1qcgxy-0008ue...@alioth.debian.org
Re: Vendor-based customization of Lintian (or profiles)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-04-19 20:23, Neil Williams wrote: > On Tue, 19 Apr 2011 20:04:47 +0200 > Niels Thykier wrote: > >>> [Needed] >>> * No code changes: >>>- It must be possible to alter whether Lintian emits a tag without >>> modifying code. >>> * Re-usable: >>>- Most profiles will likely be based on the core profile. New >>> profiles should be able to "extend" existing profile. >>>- Extended profile must be able to include tags not originally >>> in the original profile. >>>- Extended profile must be able to exclude tags originally in the >>> original profile. >>> * Add vendor/3rd party checks [Deferred]: >>>- A profile may include new checks/collections not present in the >>> Lintian package itself. >>> * A tag not included in the current profile shall not be emitted. >>>- An override for such a tag is not considered "unneeded" and must be >>> ignored. > > Emdebian tried this and came up against a few hidden assumptions in > lintian which we discussed with the lintian maintainers at the time. We > experimented with an emdebian checks file and desc file: > > http://packages.debian.org/sid/all/emdebian-crush/filelist > > If this proposal completes the final stage of that process, I will be > v.happy. :-) > Do you have a link to that debate; unfortunately I believe it was before my involvement with Lintian, so I do not believe I have seen it (unless it is covered in the DC10 notes from the BoF). > Another common requirement at work is to switch off the lintian warning > about "unsupported distributions" as we're trying to build > lintian-clean packages for our own internal repositories and it makes > apt pinning a lot easier to *not* use stable, testing, unstable or any > of the Debian ToyStory codenames. > > If that can be done with a simple file which applies across all > packages, it will just be so much easier. > Indeed :) >>> Rationale for deferring "Add checks": Fixing this is effectively to fix >>> the "third party checks" problem and this adds complexity like "how to >>> handle name clashing with checks/collections". We will have that debate >>> eventually. It is my belief that it will be easier for us to add the >>> third party checks on top on the profile system than the other way >>> around (infrastructure wise). > > That makes the third-party responsible for avoiding clashes - which is, > IMHO, the way it should work. > Maybe - I am still reluctant to include third party checks in this specification; partly because the current development has changed the below mentioned check/collection "API" and partly to keep the "size" of this specification down. >>> Also, as soon as we add third party checks our current collections as >>> well as our check interface becomes part of our API. Changing any of >>> these could possibly break other packages. >>> >>> Proposed solution >>> - >>> We add a new directory to the Lintian root called "profiles" with the >>> structure: >>> >>> profiles/ >>>debian/ >>> main.profile >>> ftp-auto-reject.profile >>>ubuntu/ >>> main.profile >>>$other_vendor/ >>> some.profile >>>default > > I think there should be support for dpkg-vendor in this situation. If > DEB_VENDOR is defined, lintian can look for that profile. Emdebian has > been doing this for some time with emvendor but not (yet) with lintian. > >>> Profiles should be specified with a new command line argument --profile >>> or the environment/lintianrc variable LINTIAN_PROFILE=. > > IMHO DEB_VENDOR is a better fit. > Hmm, dpkg-vendor/DEB_VENDOR could be a valid alternative, but I think I would like to keep LINTIAN_PROFILE as well. This would allow users/sysadmins to set their own profile that is completely unrelated to any known vendor without breaking DEB_VENDOR sensitive applications/build tools. >>> When we agree on (the basis of) an implementation (not necessarily the >>> one proposed here) I suggest we add it to the Debian wiki under >>> Lintian/Spec/VendorCustomization (or similar). >>> This way the specification does not suddenly get lost on the mailing >>> list and we can easily update it later. > > Any patches? > :-) > Unfortunately not at the moment; I wanted a bit of feedback before I started working on this. But when I start the work, I will push a branch to the lintian git. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNrdxDAAoJEAVLu599gGRCjkcQAJGuBLAd3Wiuuv2++4VQQPUn b3Kj1RrTD9tUSXQY/TsJoOngHOY8XMwwpoECn11ZBYsttA26Pi47wokRljpYALEJ R5KfMgBXOC04F7bxSgof1ZsQY5yuv8srO/tlRZHkSdwgYuNbCj2pSGeTSAPsR6Su 7X7rxJQEijZWTQwxzdZsch2BLXX2P8C0NC4ZlTthjram48Io/r512KBw2Bkn4M04 FTbj4zMWnMbR4uN2fiVmbaC2EgxuF6nc5b2S0nSZA7aGGTX/x/7vFuZ98mgmVCSf ZDvdeA2C8tOFvShKYfajIOKmni56MBq6YKrrNrbU5IBQLgHCtI3Iiab2oxqTEtp0 lGadM439nkGc8IbBLDmJeB2Z8KffxAhrjD
Re: New fields for ruby packaging
2011/4/9 Vincent Carmona : > Hi lintian team. > > Ruby packaging is changing (see > http://wiki.debian.org/Teams/Ruby/RubyInWheezy). > When checking my dsc file lintian return a warning: > ruby-globalhotkeys source: unknown-field-in-dsc ruby-versions > > In d/control I have XS-Ruby-Versions and XB-Ruby-Versions defined. > > They should be defined for all ruby packages in wheezy. Could you add > an exception to supress warnings ? > > -- > Vincent Carmona > I forget to say that I am not subscribed to this mailling list. Can you please cc me ? I do not see any response yet. If I am wrong please correct me. -- Vincent Carmona -- 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/banlktimffg12mqoj13gm_fguo0kz7oc...@mail.gmail.com
Re: Vendor-based customization of Lintian (or profiles)
On Tue, 19 Apr 2011 20:04:47 +0200 Niels Thykier wrote: > > [Needed] > > * No code changes: > >- It must be possible to alter whether Lintian emits a tag without > > modifying code. > > * Re-usable: > >- Most profiles will likely be based on the core profile. New > > profiles should be able to "extend" existing profile. > >- Extended profile must be able to include tags not originally > > in the original profile. > >- Extended profile must be able to exclude tags originally in the > > original profile. > > * Add vendor/3rd party checks [Deferred]: > >- A profile may include new checks/collections not present in the > > Lintian package itself. > > * A tag not included in the current profile shall not be emitted. > >- An override for such a tag is not considered "unneeded" and must be > > ignored. Emdebian tried this and came up against a few hidden assumptions in lintian which we discussed with the lintian maintainers at the time. We experimented with an emdebian checks file and desc file: http://packages.debian.org/sid/all/emdebian-crush/filelist If this proposal completes the final stage of that process, I will be v.happy. :-) Another common requirement at work is to switch off the lintian warning about "unsupported distributions" as we're trying to build lintian-clean packages for our own internal repositories and it makes apt pinning a lot easier to *not* use stable, testing, unstable or any of the Debian ToyStory codenames. If that can be done with a simple file which applies across all packages, it will just be so much easier. > > Rationale for deferring "Add checks": Fixing this is effectively to fix > > the "third party checks" problem and this adds complexity like "how to > > handle name clashing with checks/collections". We will have that debate > > eventually. It is my belief that it will be easier for us to add the > > third party checks on top on the profile system than the other way > > around (infrastructure wise). That makes the third-party responsible for avoiding clashes - which is, IMHO, the way it should work. > > Also, as soon as we add third party checks our current collections as > > well as our check interface becomes part of our API. Changing any of > > these could possibly break other packages. > > > > Proposed solution > > - > > We add a new directory to the Lintian root called "profiles" with the > > structure: > > > > profiles/ > >debian/ > > main.profile > > ftp-auto-reject.profile > >ubuntu/ > > main.profile > >$other_vendor/ > > some.profile > >default I think there should be support for dpkg-vendor in this situation. If DEB_VENDOR is defined, lintian can look for that profile. Emdebian has been doing this for some time with emvendor but not (yet) with lintian. > > Profiles should be specified with a new command line argument --profile > > or the environment/lintianrc variable LINTIAN_PROFILE=. IMHO DEB_VENDOR is a better fit. > > When we agree on (the basis of) an implementation (not necessarily the > > one proposed here) I suggest we add it to the Debian wiki under > > Lintian/Spec/VendorCustomization (or similar). > > This way the specification does not suddenly get lost on the mailing > > list and we can easily update it later. Any patches? :-) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpsoi6oCLH7K.pgp Description: PGP signature
Re: Vendor-based customization of Lintian (or profiles)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi (again for some)
I realised after sending my proposal that it would probably be a good
idea to (ab)use the d-derivatives list to get more opinions on this
proposal (quoted in full below).
I have set Reply-To to lintian-maint@d.o as I would like the debate on
this topic to stay on the lintian list. The web-archive for the
proposal starts at [1].
Thank you in advance,
~Niels
[1] http://lists.debian.org/debian-lint-maint/2011/04/msg00277.html
On 2011-04-19 18:14, Niels Thykier wrote:
> Hi
>
> Considering that #513663 will be closed in 2.5.0~rc3, I figured it was
> time to start a new branch. XD
> I was considering to do either Vendor-based customization or support
> third party checks (e.g. Lintian "extra"), as the subject suggests I
> think I will start with Vendor-based Lintian.
> However if you think third party checks should be given priority, let
> me know - this decision is not set in stone. :)
>
>
> Introduction
>
> The general idea of this has been to allow Debian derivatives or/and
> Debian blends to use Lintian without modifying the code. Currently
> Ubuntu has to patch Lintian every time they import because their
> requirements are slightly different than Debians.
> In the past it was just to remove a line of code here or there in the
> checks. However, now that the test-suite has been enabled they have also
> been required to update some of the tests to match these changes.
>
> If it sounds familiar then it is probably because the particular idea
> has been debated before at DebConf10[DC10] (and possibly at other times
> and places).
>
>
> Requirements
>
> This is a list of things that the solution should handle (the "how"-part
> comes later). If you feel the requirements are not reflecting what is
> really needed, do object. These requirements should form the basis for
> any suggested solution.
>
> [Needed]
> * No code changes:
>- It must be possible to alter whether Lintian emits a tag without
> modifying code.
> * Re-usable:
>- Most profiles will likely be based on the core profile. New
> profiles should be able to "extend" existing profile.
>- Extended profile must be able to include tags not originally
> in the original profile.
>- Extended profile must be able to exclude tags originally in the
> original profile.
> * Add vendor/3rd party checks [Deferred]:
>- A profile may include new checks/collections not present in the
> Lintian package itself.
> * A tag not included in the current profile shall not be emitted.
>- An override for such a tag is not considered "unneeded" and must be
> ignored.
>
> [Optional/Extra/Ideas]
> * Allow profiles to mark tags as "cannot be overridden"/"not
>overwritable".
>- Support FTP-master auto-reject as a profile.
> * Allow profiles to alter severity (but not certainty).
>- What is serious to us may be minor to others.
>- The --display-level argument should operate in terms of active
> profile's severity and not original severity
> * Allow current tag selection command arguments to affect the profile.
>- suppress-tags{,-from-file} suppresses tags even if the current
> profile would have included them.
>
>
> Rationale for deferring "Add checks": Fixing this is effectively to fix
> the "third party checks" problem and this adds complexity like "how to
> handle name clashing with checks/collections". We will have that debate
> eventually. It is my belief that it will be easier for us to add the
> third party checks on top on the profile system than the other way
> around (infrastructure wise).
> Also, as soon as we add third party checks our current collections as
> well as our check interface becomes part of our API. Changing any of
> these could possibly break other packages.
>
> Original solution
> -
> The original solution involved tagging each tag with the profiles it was
> a part of (mentioned in the follow up for [DC10]). Personally I think
> the solution suffers from a few problems.
>
> - Users/System admins cannot make their own profile without messing in
>LINTIAN_ROOT/checks/*.desc, which is usually root/root unless you use
>--root (or LINTIAN_ROOT=)/some/where/writable.
> - It does not appear to be easy to extend/reuse an existing profile
>without altering said profile.
> - Vendors may have merge conflicts if profiles are added or extended
>further up in the "food chain".
>
>
> Proposed solution
> -
> We add a new directory to the Lintian root called "profiles" with the
> structure:
>
> profiles/
>debian/
> main.profile
> ftp-auto-reject.profile
>ubuntu/
> main.profile
>$other_vendor/
> some.profile
>default
>
> profiles/default would be a symlink to the current default vendor. The
> symlink should probably be generated at build time or install time
> (probably
Re: [Pkg-fonts-devel] Lintian error with new font package name convention
Hi, Nicolas.
Thanks for the reply.
On Apr 19 2011, Nicolas Spalinger wrote:
> On 13/02/11 02:27, Rogério Brito wrote:
> > Nicolas, do you have anything written already? I'm not sure if the best
> > thing would be to have it on a repository or on a Wiki.
>
> Hi Rogério and other fellow pkg-fonts team members, a quick note to
> mention that I've had to be offline and focusing on other projects for a
> while and I apologize for my lack of involvement in the recent threads.
>
> I'm hoping to be available again soon.
OK. I've also had to had an hiatus for some personal reasons and I may be
coming soon again.
> I'll quickly mention that on the issue of fonts, their sources and
> requiring or recreating a fully Debian-specific buildpath there are
> plenty of posts from me on the issues in the archives of this list
> though (in the huge amount of spam but that's another story), please
> take a moment to look through them.
Yes, I am more malleable now :-) and I think that I will incorporate the
language of RFC 2119 in our policy.
With that, I think that some of the MUST will be changed to
SHOULD/RECOMMENDED so that some flexibility is allowed.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
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/20110419161256.ga2...@ime.usp.br
Vendor-based customization of Lintian (or profiles)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
Considering that #513663 will be closed in 2.5.0~rc3, I figured it was
time to start a new branch. XD
I was considering to do either Vendor-based customization or support
third party checks (e.g. Lintian "extra"), as the subject suggests I
think I will start with Vendor-based Lintian.
However if you think third party checks should be given priority, let
me know - this decision is not set in stone. :)
Introduction
-
The general idea of this has been to allow Debian derivatives or/and
Debian blends to use Lintian without modifying the code. Currently
Ubuntu has to patch Lintian every time they import because their
requirements are slightly different than Debians.
In the past it was just to remove a line of code here or there in the
checks. However, now that the test-suite has been enabled they have also
been required to update some of the tests to match these changes.
If it sounds familiar then it is probably because the particular idea
has been debated before at DebConf10[DC10] (and possibly at other times
and places).
Requirements
-
This is a list of things that the solution should handle (the "how"-part
comes later). If you feel the requirements are not reflecting what is
really needed, do object. These requirements should form the basis for
any suggested solution.
[Needed]
* No code changes:
- It must be possible to alter whether Lintian emits a tag without
modifying code.
* Re-usable:
- Most profiles will likely be based on the core profile. New
profiles should be able to "extend" existing profile.
- Extended profile must be able to include tags not originally
in the original profile.
- Extended profile must be able to exclude tags originally in the
original profile.
* Add vendor/3rd party checks [Deferred]:
- A profile may include new checks/collections not present in the
Lintian package itself.
* A tag not included in the current profile shall not be emitted.
- An override for such a tag is not considered "unneeded" and must be
ignored.
[Optional/Extra/Ideas]
* Allow profiles to mark tags as "cannot be overridden"/"not
overwritable".
- Support FTP-master auto-reject as a profile.
* Allow profiles to alter severity (but not certainty).
- What is serious to us may be minor to others.
- The --display-level argument should operate in terms of active
profile's severity and not original severity
* Allow current tag selection command arguments to affect the profile.
- suppress-tags{,-from-file} suppresses tags even if the current
profile would have included them.
Rationale for deferring "Add checks": Fixing this is effectively to fix
the "third party checks" problem and this adds complexity like "how to
handle name clashing with checks/collections". We will have that debate
eventually. It is my belief that it will be easier for us to add the
third party checks on top on the profile system than the other way
around (infrastructure wise).
Also, as soon as we add third party checks our current collections as
well as our check interface becomes part of our API. Changing any of
these could possibly break other packages.
Original solution
- -
The original solution involved tagging each tag with the profiles it was
a part of (mentioned in the follow up for [DC10]). Personally I think
the solution suffers from a few problems.
- Users/System admins cannot make their own profile without messing in
LINTIAN_ROOT/checks/*.desc, which is usually root/root unless you use
--root (or LINTIAN_ROOT=)/some/where/writable.
- It does not appear to be easy to extend/reuse an existing profile
without altering said profile.
- Vendors may have merge conflicts if profiles are added or extended
further up in the "food chain".
Proposed solution
- -
We add a new directory to the Lintian root called "profiles" with the
structure:
profiles/
debian/
main.profile
ftp-auto-reject.profile
ubuntu/
main.profile
$other_vendor/
some.profile
default
profiles/default would be a symlink to the current default vendor. The
symlink should probably be generated at build time or install time
(probably the former is the easiest).
The absence of the default symlink should imply debian as default
vendor to keep git clones functional.
Profiles should be specified with a new command line argument --profile
or the environment/lintianrc variable LINTIAN_PROFILE=.
should be specified as $VENDOR/$profile or $VENDOR. The
latter being short for $VENDOR/main. The actual file name of the profile
will be $VENDOR/$profile.profile and should be located in:
~/.lintian/profiles/
/etc/lintian/profiles/
$LINTIAN_ROOT/profiles/
All of these directories (if they exist) are expected to have the same
layout (as described above). Profile names cannot contain ".".
Profile file format
-
Re: [Pkg-fonts-devel] Lintian error with new font package name convention
On 13/02/11 02:27, Rogério Brito wrote: > Hi there. > > On Feb 11 2011, Nicolas Spalinger wrote: >> I'll draft over the next few days. > > Nicolas, do you have anything written already? I'm not sure if the best > thing would be to have it on a repository or on a Wiki. Hi Rogério and other fellow pkg-fonts team members, a quick note to mention that I've had to be offline and focusing on other projects for a while and I apologize for my lack of involvement in the recent threads. I'm hoping to be available again soon. I'll quickly mention that on the issue of fonts, their sources and requiring or recreating a fully Debian-specific buildpath there are plenty of posts from me on the issues in the archives of this list though (in the huge amount of spam but that's another story), please take a moment to look through them. > Seeing as everything is still *very* rough on the edges, I would prefer it > to not be available to the public until it is, at least, not > embarrassing. :-) > > > Regards, Cheers, -- Nicolas Spalinger, SIL NRSI volunteer - http://scripts.sil.org Debian fonts task force - http://pkg-fonts.alioth.debian.org Open font community - http://planet.open-fonts.org -- 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/4dada655.5020...@sil.org
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-144-g7e3e4fa
The following commit has been merged in the master branch:
commit 7e3e4fafa130ee7ea0c1445491aedf21c935a9e7
Author: Niels Thykier
Date: Tue Apr 19 14:15:05 2011 +0200
Fixed test failure with d/changelog
diff --git a/debian/changelog b/debian/changelog
index 8379ffa..3012d31 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -39,7 +39,7 @@ lintian (2.5.0~rc3) UNRELEASED; urgency=low
+ [NT] Added dir-or-file-in-run tag. (Closes: #623031)
* checks/java{,.desc}:
+ [NT] Added file based on patches submitted by Vicent Fourmond.
- - This new file checks for jar files in weird locations.
+ This new file checks for jar files in weird locations.
(Closes: #620829, #575447)
* checks/manpages:
+ [NT] Fixed false-positive binary-without-manpage when the
--
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/e1qc9uu-ew...@alioth.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.0-rc2-144-g7e3e4fa
The following commit has been merged in the master branch:
commit c5880b0fadd3fed72adf9f91f1032bc89c6596c4
Author: Niels Thykier
Date: Tue Apr 19 14:09:50 2011 +0200
Throw away info objects when checks are done
This avoids memory being used by info-caches that will never be
used again. This are thrown out when the entire group has been
processed.
diff --git a/frontend/lintian b/frontend/lintian
index ff73cc7..1fff26e 100755
--- a/frontend/lintian
+++ b/frontend/lintian
@@ -1037,7 +1037,10 @@ my %overrides;
foreach my $gname (sort $pool->get_group_names()) {
my $group = $pool->get_group($gname);
unpack_group($group);
-process_group($group) if $action eq 'check';
+if ($action eq 'check'){
+ process_group($group);
+ clear_group_cache($group);
+}
}
$TAGS->file_end();
@@ -1528,6 +1531,18 @@ sub process_group {
return 1;
}
+
+# cleans the cache of all elements in this group - this avoids
+# memory being hogged by packages/groups that have been checked
+# and will not be checked again.
+sub clear_group_cache {
+my ($group) = @_;
+foreach my $proc ($group->get_processables()){
+ $proc->clear_cache;
+}
+return 1;
+}
+
# }}}
# {{{ Exit handler.
diff --git a/lib/Lintian/Processable.pm b/lib/Lintian/Processable.pm
index 5fd4948..21ba8a2 100644
--- a/lib/Lintian/Processable.pm
+++ b/lib/Lintian/Processable.pm
@@ -144,6 +144,18 @@ sub info{
return $info;
}
+=item $proc->clear_cache()
+
+Discard the info element, so the memory used by it can be reclaimed.
+Mostly useful when checking a lot of packages (e.g. on lintian.d.o).
+
+=cut
+
+sub clear_cache {
+my ($self) = @_;
+delete $self->{info};
+}
+
=item $proc->lab_pkg([$lpkg])
Returns or sets the L element for this processable.
--
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/e1qc9tx-sv...@alioth.debian.org
Bug#623310: lintian: newer-standards-version reports older policy than what is current
Package: lintian Version: 2.5.0~rc2 Severity: minor Whiel making Debian package and running lintian I see: W: winetricks source: newer-standards-version 3.9.2 (current is 3.9.1) But, the latest 3.9.2 is installed: $ apt-cache policy debian-policy debian-policy: Installed: 3.9.2.0 Candidate: 3.9.2.0 Package pin: 3.9.2.0 Version table: *** 3.9.2.0 1001 990 http://ftp.se.debian.org/debian/ testing/main amd64 Packages 500 http://ftp.fi.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.21.0.20110327-3 The GNU assembler, linker and bina ii diffstat 1.54-1produces graph of changes introduc ii dpkg-dev 1.16.0.2 Debian package development tools ii file 5.04-5+b1 Determines file type using "magic" ii gettext0.18.1.1-3GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libemail-valid-perl0.184-1 Perl module for checking the valid ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.2.0-1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.58-1module to manipulate and access UR ii locales2.11.2-11 Embedded GNU C Library: National L ii man-db 2.5.9-4 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-19 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch (no description available) ii libtext-template-perl 1.45-2 Text::Template perl module ii man-db2.5.9-4on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419080723.9052.80601.report...@websvn.cante.net
Processed: forcibly merging 621667 623310
Processing commands for cont...@bugs.debian.org: > forcemerge 621667 623310 Bug#621667: lintian: update for Policy 3.9.2.0 needed Bug#623310: lintian: newer-standards-version reports older policy than what is current Forcibly Merged 621667 623310. > thanks Stopping processing here. Please contact me if you need assistance. -- 621667: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621667 623310: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623310 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.130320070815652.transcr...@bugs.debian.org
