Bug#458831: lintian: extra-license-file detects non-license files
On Thursday 03 January 2008, Russ Allbery wrote: I'm not sure what to do with these, since they really are extra copies of the licenses without any useful change (unlike the *.html versions): W: kdelibs-data: extra-license-file usr/share/doc/kde/HTML/en/common/fdl-license W: kdelibs-data: extra-license-file usr/share/doc/kde/HTML/en/common/gpl-license W: kdelibs-data: extra-license-file usr/share/doc/kde/HTML/en/common/lgpl-license You could make them symlinks to common-licenses. That's probably what I'd do. Yeah. I have seen those - and it is also what I think I would do one day. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian pages available for testing
Thijs Kinkhorst [EMAIL PROTECTED] writes: On Thursday 3 January 2008 01:16, Russ Allbery wrote: http://lintian.debian.org/reports-testing/ This looks good in general, it's a clear improvement over what we have. Thanks! * The HTML pages are now templatized (using Text::Template). The core of many of the pages is still generated by some not-horribly-pleasant Perl embedded in the templates, but all of the transformation from data to HTML should now be in the templates so that someone can modify them independent of the main script. Great. Would this include the capability to wrap different tag severities in different HTML-tags so each could get their own CSS class? Yes, that should be fairly straightforward. That sort of modification will require changing the Perl, but hopefully it's not too hideous to read. (I admit that I made the Perl a bit ugly to make the HTML pretty, a long-standing habit of mine from writing other generator software but possibly not the right choice.) The HTML output from inside the templates would have probably benefitted from using some nice module that turns trees into HTML or something, but given that lintian.d.o's host is still running oldstable, I decided not to test my luck with fancy Perl modules. If you want to take a look at how good (or bad) the templates look, the ones that generated those pages are in: /org/lintian.debian.org/lintian-test/reporting/templates on gluck.d.o. I was thinking that this could be better implemented by generating one page per maintainer with all tags, and that I and O are hidden elements by default. A link on the page would then just toggle the visibility of that CSS class (just like the legend at the top of the DDPO). This sounds like a great idea to me; it's just beyond my personal HTML foo. However, the new generation system creates a style sheet, which is currently almost empty, and the idea was that anyone who knows how to do things like this could centralize all the necessary CSS there. The advantage is less output to generate and no need to reload a page between toggles. A possible drawback could be that the E/W pages get a larger filesize. Are there significantly more I+O tags so that the 'full' pages are getting very large? gluck:/org/lintian.debian.org/www/reports-testing du -sh full maintainer 30M full 20M maintainer Nah. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian pages available for testing
On to, 2008-01-03 at 08:48 +0100, Thijs Kinkhorst wrote: I was thinking that this could be better implemented by generating one page per maintainer with all tags, and that I and O are hidden elements by default. A link on the page would then just toggle the visibility of that CSS class (just like the legend at the top of the DDPO). That would mean that it gets harder to get one or the other version of the page: it's no longer enough to just go to the page, you also have to go click on something else as well. For something that is a simple report page, I don't think that's warranted. For DDPO it's more warranted, given that DDPO is more of an application, and also seems to be able to remember your state. For lintian, I don't think it's worth the complication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian pages available for testing
On Thu, January 3, 2008 10:00, Lars Wirzenius wrote: That would mean that it gets harder to get one or the other version of the page: it's no longer enough to just go to the page, you also have to go click on something else as well. For something that is a simple report page, I don't think that's warranted. For DDPO it's more warranted, given that DDPO is more of an application, and also seems to be able to remember your state. For lintian, I don't think it's worth the complication. You could make it start out with the full output if you request it with a ?full=1 URL parameter. That could satisfy both wishes. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian pages available for testing
Russ Allbery wrote: Thijs Kinkhorst [EMAIL PROTECTED] writes: On Thursday 3 January 2008 01:16, Russ Allbery wrote: http://lintian.debian.org/reports-testing/ This looks good in general, it's a clear improvement over what we have. Thanks! * The HTML pages are now templatized (using Text::Template). The core of many of the pages is still generated by some not-horribly-pleasant Perl embedded in the templates, but all of the transformation from data to HTML should now be in the templates so that someone can modify them independent of the main script. Great. Would this include the capability to wrap different tag severities in different HTML-tags so each could get their own CSS class? Yes, that should be fairly straightforward. That sort of modification will require changing the Perl, but hopefully it's not too hideous to read. (I admit that I made the Perl a bit ugly to make the HTML pretty, a long-standing habit of mine from writing other generator software but possibly not the right choice.) The HTML output from inside the templates would have probably benefitted from using some nice module that turns trees into HTML or something, but given that lintian.d.o's host is still running oldstable, I decided not to test my luck with fancy Perl modules. If you want to take a look at how good (or bad) the templates look, the ones that generated those pages are in: /org/lintian.debian.org/lintian-test/reporting/templates on gluck.d.o. Not being a DD, I probably can't access this. My current forward thinking on the presentation of reports like this is to have the script deliver pure XML and do all the formatting with XSL+CSS. That way the formatter wouldn't need to care what the Perl script was doing. I don't think my HTML-fu is any better than yours, Russ. In fact I could learn a thing or two. I don't understand why [dt id=package-name] when #package-name isn't referenced in the .css, but that's probably because I'm only looking at this from a formatting POV. Otherwise this looks like sensible HTML. I'd be happy to put some energy into formatting the output, but I don't want to have to even read any Perl. XSL basically turns an XML tree into (X)HTML and could easily wrap different tag severities in different HTML-tags so each could get their own CSS class. I may be being horribly naive here, in which case, a gentle brief explanation why would help me understand better if anyone feels moved. ;) My primary interest in this is as one of the Debian derivatives who might ultimately want to put up their own themed (or further filtered) pages. cheers, tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456318: lintian: rpath check for games should include games dir
On Wed, Jan 02, 2008 at 09:10:28PM -0800, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
FHS chapter 4, at the end of the paragraph on Specific options in
/usr/share, says:
Similarly, a /usr/lib/games hierarchy may be used in addition to
the /usr/share/games hierarchy if the distributor wishes to
place some game data there.
Neither policy nor developers' reference say anything about this, but I
think most games choose to use both /usr/share/games and /usr/lib/games
for game data. The good thing about this is that it makes it very easy
to do things to all games at once (exclude them from backups, for
example).
The more that I look at this, the more that I think this isn't a good
idea. FHS doesn't say anything about shared libraries, only game data,
which doesn't really sound like shared libraries to me. Putting shared
libraries in additional places in the system is tricky and raises the
possibility of conflicts between different shared libraries. And putting
shared libraries in a location that isn't in ld.so.conf requires setting
an rpath, which has potentially bad interactions with multiarch support.
This is true, but this isn't specific to games. Other programs can put
their data, including private shared libraries, in
/usr/{share,lib}/packagename. The difference for games is only that
they may use /usr/{share,lib}/games/packagename instead.
Policy says about this in 10.2:
Shared object files (often .so files) that are not public
libraries, that is, they are not meant to be linked to by third
party executables (binaries of other packages), should be
installed in subdirectories of the /usr/lib directory. Such
files are exempt from the rules that govern ordinary shared
libraries, except that they must not be installed executable and
should be stripped.
The actual subdirectory isn't mentioned, but everyone seems to agree
that it should be /usr/lib/packagename, or a subdirectory thereof. In
case of games, /usr/lib/games/packagename is used, just as it is for
other game data.
That there's nothing in Policy about this is definitely a problem given
how often issues about setting rpath come up. I think we need to add
something to the binaries section on how to handle rpath.
Well, the piece I quoted above is something, but it doesn't mention
rpath at all (and the footnote talks about plugins used with dlopen, not
libraries linked with rpath).
The current lintian rpath check will only warn if there is an rpath set,
and it is not set to /usr/lib/packagename. I still think it is
reasonable to expand that to or, for games, to
/usr/lib/games/packagename. The problem you describe is not specific
for games, but rather a problem with rpath in general. So while it may
be a good idea to forbid rpath completely, and force people packaging
programs which use it upstream to convert the build system to use static
libraries, for example, I don't think this change should depend on that
(well, the changed text would be removed if that is decided, of course).
I'm going to open a Policy bug on this and block this bug on that one.
Opening a policy bug seems good, but please don't make it
games-specific. I don't think that this bug needs to blocked on that,
because they are two quite different issues IMO (using private shared
libraries with rpath from subdirectories of /usr/lib and games use
/usr/lib/games/packagename for arch-dependent data). But if I didn't
convince you about that, feel free to set the block anyway. ;-)
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
Bug#458896: lintian: Wrong interpreter information w.r.t. pike
Package: lintian lintian/checks/scripts currently lists pike, pike7, and pike7.6 as valid interpreters, associating them with packages of the same names. Currently, the available Pike interpreters are /usr/bin/pike7.6, provided by pike7.6-core, and /usr/bin/pike7.7, provided by pike7.7-core. /usr/bin/pike is managed by the alternatives system and could point to either - it should probably not be used by a packaged script. The previous maintainer was going to rename pike7.7 as pike7.8, which is what it will become when upstream releases it as stable, and I intend to follow that track soon. Pike needs a policy similar to Python's or Perl's with a default version, so things might change, but in the meantime, can you update Lintian in accordance with the above information? -- Magnus Holmgren New pike* (co)maintainer signature.asc Description: This is a digitally signed message part.
Re: New lintian pages available for testing
tim hall [EMAIL PROTECTED] writes: Russ Allbery wrote: If you want to take a look at how good (or bad) the templates look, the ones that generated those pages are in: /org/lintian.debian.org/lintian-test/reporting/templates on gluck.d.o. Not being a DD, I probably can't access this. http://svn.wolffelaar.nl/lintian/trunk/reporting/templates/ will also work. My current forward thinking on the presentation of reports like this is to have the script deliver pure XML and do all the formatting with XSL+CSS. That way the formatter wouldn't need to care what the Perl script was doing. I'm certainly happy to accept someone else's work in that area, and the restructuring of html_reports should make it much easier to do this. I probably won't have time for this significant of a rearchitecture myself, though. When making major changes like this, please do be aware that lintian.d.o is still running on an oldstable system, so cutting-edge Perl modules probably won't work. I don't think my HTML-fu is any better than yours, Russ. In fact I could learn a thing or two. I don't understand why [dt id=package-name] when #package-name isn't referenced in the .css, but that's probably because I'm only looking at this from a formatting POV. Otherwise this looks like sensible HTML. This is for cross-links from other systems, such as the PTS, and within the lintian.d.o pages (such as from the tags page). I'd be happy to put some energy into formatting the output, but I don't want to have to even read any Perl. XSL basically turns an XML tree into (X)HTML and could easily wrap different tag severities in different HTML-tags so each could get their own CSS class. I may be being horribly naive here, in which case, a gentle brief explanation why would help me understand better if anyone feels moved. ;) Well, in order to start with an XML tree to do transforms, someone is going to need to write the Perl to generate that from Lintian's log. I personally don't have time to do that work. For better or for worse, Lintian is written in Perl (which does have a rich set of XML libraries). Another option would be to rewrite the whole reporting infrastructure in Python, but that's a much bigger project and you'd have to duplicate some of Lintian's core libraries to get at things like tag descriptions and package list parsing. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: unblock 456318 with 458824
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.11 unblock 456318 with 458824 Bug#458824: better specification for when rpath is permitted is needed Bug#456318: [checks/binaries] allow /usr/lib/games rpath for games binaries Was blocked by: 458824 Blocking bugs of 456318 removed: 458824 End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New lintian pages available for testing
Russ Allbery wrote: tim hall [EMAIL PROTECTED] writes: Russ Allbery wrote: http://svn.wolffelaar.nl/lintian/trunk/reporting/templates/ will also work. Thanks. :) My current forward thinking on the presentation of reports like this is to have the script deliver pure XML and do all the formatting with XSL+CSS. That way the formatter wouldn't need to care what the Perl script was doing. I'm certainly happy to accept someone else's work in that area, and the restructuring of html_reports should make it much easier to do this. I probably won't have time for this significant of a rearchitecture myself, though. Well, in order to start with an XML tree to do transforms, someone is going to need to write the Perl to generate that from Lintian's log. I personally don't have time to do that work. For better or for worse, Lintian is written in Perl (which does have a rich set of XML libraries). Another option would be to rewrite the whole reporting infrastructure in Python, but that's a much bigger project and you'd have to duplicate some of Lintian's core libraries to get at things like tag descriptions and package list parsing. OK, understood. I'm not offering to re-invent the wheel at this stage. Having just looked at how simple the templates are, I'd be more than happy to do some work on the HTML and add some suitable CSS as and when appropriate. cheers, tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
homepage in udebs?
Hi all, I'm sponsoring ttf-khmeros, which produces a font udeb for d-i. The latest ttf-khmeros update moved the homepage from the package description to the new dpkg source package field. As a result, lintian complains with I: ttf-khmeros-udeb udeb: unknown-field-in-control homepage. Is this a bug in dpkg-buildpackage for propagating the homepage to the udeb, or a bug in lintian? I'm inclined to think the former, as homepages probably aren't much use in udebs. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: homepage in udebs?
Paul Wise [EMAIL PROTECTED] writes: I'm sponsoring ttf-khmeros, which produces a font udeb for d-i. The latest ttf-khmeros update moved the homepage from the package description to the new dpkg source package field. As a result, lintian complains with I: ttf-khmeros-udeb udeb: unknown-field-in-control homepage. Is this a bug in dpkg-buildpackage for propagating the homepage to the udeb, or a bug in lintian? I'm inclined to think the former, as homepages probably aren't much use in udebs. I'm honestly not sure. udebs are a bizarre special case with no complete specification that I know of, so there isn't really a reference for what they should and shouldn't have relative to a regular package. (Ideally, we should specify udebs in Policy, but part of the point of udebs is that they often don't comply with Policy, so this is tricky.) I'd check with the d-i team and ask them their opinion. I'm happy to modify lintian to match if needed. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: homepage in udebs?
On Thu, 2008-01-03 at 17:59 -0800, Russ Allbery wrote: I'd check with the d-i team and ask them their opinion. I'm happy to modify lintian to match if needed. Thanks for that. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
lintian: r1103 - in trunk: checks debian
Author: rra
Date: 2008-01-04 04:47:22 +0100 (Fri, 04 Jan 2008)
New Revision: 1103
Modified:
trunk/checks/binaries
trunk/debian/changelog
Log:
* checks/binaries:
+ [RA] Some packages include debugging symbols in the main package, so
don't warn about unstripped binaries in ../lib/debug as well.
Modified: trunk/checks/binaries
===
--- trunk/checks/binaries 2008-01-03 07:59:16 UTC (rev 1102)
+++ trunk/checks/binaries 2008-01-04 03:47:22 UTC (rev 1103)
@@ -190,15 +190,15 @@
# stripped?
if ($info =~ m,not stripped\s*$,o) {
# Is it an object file (which generally can not be stripped),
- # a kernel module, or perhaps a debugging package?
+ # a kernel module, debugging symbols, or perhaps a debugging package?
# Ocaml executables are exempted, see #252695
unless ($file =~ m,\.k?o$, or $pkg =~ m/-dbg$/ or $pkg =~ m/debug/
- or exists $OCAML{$file}) {
+ or $file =~ m,/lib/debug/, or exists $OCAML{$file}) {
tag unstripped-binary-or-object, $file;
}
} else {
# stripped but a debug or profiling library?
- if (($file =~ m,lib/debug/,o) or ($file =~ m,lib/profile/,o)) {
+ if (($file =~ m,/lib/debug/,o) or ($file =~ m,/lib/profile/,o)) {
tag library-in-debug-or-profile-should-not-be-stripped, $file;
} else {
# appropriately stripped, but is it stripped enough?
@@ -298,4 +298,8 @@
1;
+# Local Variables:
+# indent-tabs-mode: t
+# cperl-indent-level: 4
+# End:
# vim: syntax=perl ts=8 sw=4
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-03 07:59:16 UTC (rev 1102)
+++ trunk/debian/changelog 2008-01-04 03:47:22 UTC (rev 1103)
@@ -1,5 +1,8 @@
lintian (1.23.42) UNRELEASED; urgency=low
+ * checks/binaries:
++ [RA] Some packages include debugging symbols in the main package, so
+ don't warn about unstripped binaries in ../lib/debug as well.
* checks/changelog-file{.desc,}:
+ [RA] Don't spell-check lines that include the word spelling.
Thanks, Andreas Hoenen. (Closes: #456515)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1104 - in trunk: checks debian
Author: rra
Date: 2008-01-04 05:00:11 +0100 (Fri, 04 Jan 2008)
New Revision: 1104
Modified:
trunk/checks/binaries
trunk/debian/changelog
Log:
+ [RA] Allow rpath pointing to /usr/lib/games/package. Thanks, Bas
Wijnen. (Closes: #456318)
Modified: trunk/checks/binaries
===
--- trunk/checks/binaries 2008-01-04 03:47:22 UTC (rev 1103)
+++ trunk/checks/binaries 2008-01-04 04:00:11 UTC (rev 1104)
@@ -213,7 +213,7 @@
# rpath is disallowed, except in private directories
if (exists $RPATH{$file}
-grep(!m#^/usr/lib/\Q$pkg\E(?:/|$)#, split(/:/, $RPATH{$file}))
+grep { !m,^/usr/lib/(games/)?\Q$pkg\E(?:/|\z), } split(/:/,
$RPATH{$file})
) {
tag binary-or-shlib-defines-rpath, $file $RPATH{$file};
}
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-04 03:47:22 UTC (rev 1103)
+++ trunk/debian/changelog 2008-01-04 04:00:11 UTC (rev 1104)
@@ -3,6 +3,8 @@
* checks/binaries:
+ [RA] Some packages include debugging symbols in the main package, so
don't warn about unstripped binaries in ../lib/debug as well.
++ [RA] Allow rpath pointing to /usr/lib/games/package. Thanks, Bas
+ Wijnen. (Closes: #456318)
* checks/changelog-file{.desc,}:
+ [RA] Don't spell-check lines that include the word spelling.
Thanks, Andreas Hoenen. (Closes: #456515)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Lintian bugs fixed in revision r1104
Processing commands for [EMAIL PROTECTED]: package lintian Ignoring bugs not assigned to: lintian # Fixed in r1104 by rra tag 456318 + pending Bug#456318: [checks/binaries] allow /usr/lib/games rpath for games binaries There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1105 - in trunk: checks debian testset
Author: rra
Date: 2008-01-04 05:18:28 +0100 (Fri, 04 Jan 2008)
New Revision: 1105
Modified:
trunk/checks/menu-format
trunk/checks/menu-format.desc
trunk/debian/changelog
trunk/testset/tags.binary
Log:
* checks/menu-format{.desc,}:
+ [RA] Warn about use of su wrappers other than su-to-root for desktop
and Live CD support. Thanks, Daniel Baumann. (Closes: #453931)
Modified: trunk/checks/menu-format
===
--- trunk/checks/menu-format2008-01-04 04:00:11 UTC (rev 1104)
+++ trunk/checks/menu-format2008-01-04 04:18:28 UTC (rev 1105)
@@ -884,6 +884,9 @@
}
}
tag 'su-wrapper-without--c', $location $wrapper unless $cmd;
+ if ($wrapper !~ /su-to-root/) {
+ tag 'su-wrapper-not-su-to-root', $location $wrapper;
+ }
} else {
$cmd = $com[0];
}
@@ -893,4 +896,8 @@
1;
+# Local Variables:
+# indent-tabs-mode: t
+# cperl-indent-level: 4
+# End:
# vim: syntax=perl ts=8 sw=4
Modified: trunk/checks/menu-format.desc
===
--- trunk/checks/menu-format.desc 2008-01-04 04:00:11 UTC (rev 1104)
+++ trunk/checks/menu-format.desc 2008-01-04 04:18:28 UTC (rev 1105)
@@ -142,19 +142,29 @@
Tag: su-wrapper-without--c
Type: error
-Info: The menu item command uses an su wrapper such as su-to-root without
- the -c flag. This is a syntax error.
+Info: The menu item command or desktop file uses an su wrapper such as
+ su-to-root without the -c flag. This is a syntax error.
Ref: su-to-root(1)
Tag: su-to-root-with-usr-sbin
Type: warning
-Info: The menu item command uses su-to-root as /usr/sbin/su-to-root
- Since sarge su-to-root is located in /usr/bin and /usr/sbin/su-to-root
- is only a compatibility symlink that may get dropped in the future.
+Info: The menu item or desktop file command uses su-to-root as
+ /usr/sbin/su-to-root. Since sarge su-to-root is located in /usr/bin and
+ /usr/sbin/su-to-root is only a compatibility symlink that may get dropped
+ in the future.
.
Since su-to-root is now located in /usr/bin you can use it without
absolute path now.
+Tag: su-wrapper-not-su-to-root
+Type: warning
+Info: The menu item or desktop file command uses an su wrapper other than
+ su-to-root. On Debian systems, please use ttsu-to-root -X/tt, which
+ will pick the correct wrapper based on what's installed on the system and
+ the current desktop environment. Using su-to-root is also important for
+ Live CD systems which need to use sudo rather than su. su-to-root
+ permits global configuration to use sudo.
+
Tag: menu-item-needs-dwww
Type: warning
Info: The menu item has needs=dwww. This is deprecated. Instead, you should
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-04 04:00:11 UTC (rev 1104)
+++ trunk/debian/changelog 2008-01-04 04:18:28 UTC (rev 1105)
@@ -36,10 +36,12 @@
* checks/init.d{.desc,}:
+ [RA] Warn of init scripts that list S in their Default-Stop LSB
keyword. Thanks, Petter Reinholdtsen. (Closes: #458596)
- * checks/menu-format.desc:
+ * checks/menu-format{.desc,}:
+ [RA] Fix non-wm-module-in-wm-modules-menu-section pluralization to
match the check and reword the long description to be hopefully
clearer. Thanks, MartÃn Ferrari. (Closes: #457527)
++ [RA] Warn about use of su wrappers other than su-to-root for desktop
+ and Live CD support. Thanks, Daniel Baumann. (Closes: #453931)
* checks/menus{.desc,}:
+ [RA] Spelling errors in doc-base files should only be warnings. Do
picky spelling and capitalization checks on the abstract and title
Modified: trunk/testset/tags.binary
===
--- trunk/testset/tags.binary 2008-01-04 04:00:11 UTC (rev 1104)
+++ trunk/testset/tags.binary 2008-01-04 04:18:28 UTC (rev 1105)
@@ -112,6 +112,8 @@
W: binary: spelling-error-in-news-debian usefull useful
W: binary: su-to-root-with-usr-sbin /usr/lib/menu/binary:4
W: binary: su-to-root-with-usr-sbin /usr/share/menu/binary:4
+W: binary: su-wrapper-not-su-to-root /usr/lib/menu/binary:3 sux
+W: binary: su-wrapper-not-su-to-root /usr/share/menu/binary:3 sux
W: binary: superfluous-clutter-in-homepage http://lintian.debian.org/
W: binary: symlink-should-be-relative usr/share/doc/binary/html/ch3.html
/usr/share/doc/binary/htm/ch1.html
W: binary: syntax-error-in-debian-changelog line 16 couldn't parse date The,
15 Apr 2004 23:33:51 +0200
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Lintian bugs fixed in revision r1105
Processing commands for [EMAIL PROTECTED]: package lintian Ignoring bugs not assigned to: lintian # Fixed in r1105 by rra tag 453931 + pending Bug#453931: lintian: Warn when using gksu/kdesu instead of su-to-root There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1106 - in trunk: checks debian testset testset/binary/debian testset/foo++/debian testset/libbaz/debian testset/scripts/debian
Author: rra
Date: 2008-01-04 05:54:12 +0100 (Fri, 04 Jan 2008)
New Revision: 1106
Added:
trunk/testset/foo++/debian/copyright
trunk/testset/scripts/debian/copyright
Modified:
trunk/checks/copyright-file
trunk/checks/copyright-file.desc
trunk/debian/changelog
trunk/testset/binary/debian/control
trunk/testset/binary/debian/copyright
trunk/testset/foo++/debian/control
trunk/testset/libbaz/debian/control
trunk/testset/libbaz/debian/copyright
trunk/testset/scripts/debian/control
trunk/testset/scripts/debian/rules
trunk/testset/tags.binary
trunk/testset/tags.scripts
Log:
* checks/copyright-file{.desc,}:
+ [RA] Warn about packages covered by the GPL and linked with libssl
that don't list other common licenses or mention a license exception
or exemption. Requested by Joerg Jaspert. (Closes: #454238)
Modified: trunk/checks/copyright-file
===
--- trunk/checks/copyright-file 2008-01-04 04:18:28 UTC (rev 1105)
+++ trunk/checks/copyright-file 2008-01-04 04:54:12 UTC (rev 1106)
@@ -176,11 +176,15 @@
tag old-fsf-address-in-copyright-file, ;
}
+# Whether the package is covered by the GPL, used later for the libssl check.
+my $gpl;
+
if (length($_) 12000
and ((m/\bGNU GENERAL PUBLIC LICENSE\s*TERMS AND CONDITIONS FOR COPYING,
DISTRIBUTION AND MODIFICATION\b/m
and m/\bVersion 2\s/)
or (m/\bGNU GENERAL PUBLIC LICENSE\s*Version 3/ and m/\bTERMS AND
CONDITIONS\s/))) {
tag copyright-file-contains-full-gpl-license;
+$gpl = 1;
}
if (length($_) 12000
@@ -221,6 +225,7 @@
tag copyright-should-refer-to-common-license-file-for-lgpl;
} elsif (m/GNU General Public License/i or m/\bGPL\b/) {
tag copyright-should-refer-to-common-license-file-for-gpl;
+$gpl = 1;
}
if (m,Upstream Author\(s\),) {
@@ -233,6 +238,22 @@
spelling_check('spelling-error-in-copyright', $_);
+# Now, check for linking against libssl if the package is covered by the GPL.
+# (This check was requested by ftp-master.) First, see if the package is
+# under the GPL alone and try to exclude packages with a mix of GPL and LGPL
+# or Artistic licensing or with an exception or exemption.
+if ($gpl || m,/usr/share/common-licenses/GPL,) {
+unless (m,exception|exemption|/usr/share/common-licenses/(?!GPL)\S,) {
+if (open(DEP, '', 'fields/depends')) {
+my @depends = split (/\s*,\s*/, scalar DEP);
+close DEP;
+if (grep { /^libssl[0-9.]+(\s|\z)/ !/\|/ } @depends) {
+tag 'possible-gpl-code-linked-with-openssl';
+}
+}
+}
+}
+
} # /run
# ---
@@ -265,4 +286,8 @@
1;
+# Local Variables:
+# indent-tabs-mode: t
+# cperl-indent-level: 4
+# End:
# vim: syntax=perl ts=8 sw=4
Modified: trunk/checks/copyright-file.desc
===
--- trunk/checks/copyright-file.desc2008-01-04 04:18:28 UTC (rev 1105)
+++ trunk/checks/copyright-file.desc2008-01-04 04:54:12 UTC (rev 1106)
@@ -195,3 +195,12 @@
Info: Lintian found a spelling error in the copyright file. Lintian has a
list of common misspellings that it looks for. It does not have a
dictionary like a spelling checker does.
+
+Tag: possible-gpl-code-linked-with-openssl
+Type: warning
+Info: This package appears to be covered by the GNU GPL but depends on
+ the OpenSSL libssl package and does not mention a license exemption or
+ exception for OpenSSL in its copyright file. The GPL (including version
+ 3) is incompatible with some terms of the OpenSSL license, and therefore
+ Debian does not allow GPL-licensed code linked with OpenSSL libraries
+ unless there is a license exception explicitly permitting this.
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-04 04:18:28 UTC (rev 1105)
+++ trunk/debian/changelog 2008-01-04 04:54:12 UTC (rev 1106)
@@ -16,6 +16,10 @@
+ [RA] Include the package name in stronger-dependency-implies-weaker.
+ [RA] Fix stronger-dependency-implies-weaker description cut and
paste error. Thanks, Rafael Laboissiere. (Closes: #456405)
+ * checks/copyright-file{.desc,}:
++ [RA] Warn about packages covered by the GPL and linked with libssl
+ that don't list other common licenses or mention a license exception
+ or exemption. Requested by Joerg Jaspert. (Closes: #454238)
* checks/debian-readme{.desc,}:
+ Combine readme-debian-{is,contains}-debmake-template and be less
particular about the exact formatting of the dh-make template.
Modified: trunk/testset/binary/debian/control
===
--- trunk/testset/binary/debian/control 2008-01-04 04:18:28 UTC (rev 1105)
+++ trunk/testset/binary/debian/control 2008-01-04 04:54:12 UTC (rev 1106)
@@
Processed: Lintian bugs fixed in revision r1106
Processing commands for [EMAIL PROTECTED]: package lintian Ignoring bugs not assigned to: lintian # Fixed in r1106 by rra tag 454238 + pending Bug#454238: [copyright-file] warn if GPL code links to libssl without an exception There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1107 - in trunk: checks debian
Author: rra Date: 2008-01-04 06:08:31 +0100 (Fri, 04 Jan 2008) New Revision: 1107 Modified: trunk/checks/fields.desc trunk/debian/changelog Log: * checks/fields.desc: + [RA] Remove X.X.X versions from the debian-revision-not-well-formed long description. (Closes: #456286) + [RA] Update references and binary-NMU version descriptions. Modified: trunk/checks/fields.desc === --- trunk/checks/fields.desc2008-01-04 04:54:12 UTC (rev 1106) +++ trunk/checks/fields.desc2008-01-04 05:08:31 UTC (rev 1107) @@ -41,9 +41,9 @@ Tag: debian-revision-not-well-formed Type: warning -Info: The debian version part (the part after the -) should consist of one to - three dot-separated parts: one for maintainer release, two for source-NMU, - three for binary NMU. +Info: The debian version part (the part after the -) should consist of one + or two dot-separated parts: one for a regular maintainer release or two + for a source-NMU, Tag: debian-revision-should-not-be-zero Type: warning @@ -52,7 +52,7 @@ always have a higher version number than a Non-Maintainer upload: a NMU could have been prepared which introduces this upstream version with Debian-revision -0.1 -Ref: devref 5.11.4.1 +Ref: devref 5.11.2 Tag: no-architecture-field Type: error @@ -626,9 +626,9 @@ Type: warning Ref: devref 5.10.2.1 Info: The version number of a binary NMU should be formed by appending - '+b' and a digit to the source version. This version scheme is + tt+b/tt and a digit to the source version. This version scheme is special-cased by the archive software. The -x.x.x version number style - is considered obsolete. + should no longer be used. Tag: binary-nmu-debian-revision-in-source Type: warning @@ -636,8 +636,8 @@ Info: The version number of your source package ends in +b and a number or has a Debian revision containing three parts. These version numbers are used by binary NMUs and should not be used as the source version. (The - +b form is the current standard; the three-part version number is the old - standard.) + +b form is the current standard; the three-part version number now + obsolete.) Tag: redundant-bugs-field Type: warning @@ -647,7 +647,7 @@ Tag: build-depends-on-build-essential Type: error -Ref: 7.6 +Ref: policy 7.6 Info: You depends on the build-essential package, which is only a meta-package depending on build tools that have to be installed in all build environments. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2008-01-04 04:54:12 UTC (rev 1106) +++ trunk/debian/changelog 2008-01-04 05:08:31 UTC (rev 1107) @@ -31,6 +31,10 @@ * checks/fields: + [RA] Handle double-colon rules when checking that build dependencies match debian/rules. (Closes: #457501) + * checks/fields.desc: ++ [RA] Remove X.X.X versions from the debian-revision-not-well-formed + long description. (Closes: #456286) ++ [RA] Update references and binary-NMU version descriptions. * checks/files: + [RA] Ignore zero-length files in /usr/share/doc/examples. + [RA] The underFooLicense.docbook files from KDE are not license -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Lintian bugs fixed in revision r1107
Processing commands for [EMAIL PROTECTED]: package lintian Ignoring bugs not assigned to: lintian # Fixed in r1107 by rra tag 456286 + pending Bug#456286: lintian: debian-revision-not-well-formed mentions old binNMU style Tags were: patch Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456286: lintian: debian-revision-not-well-formed mentions old binNMU style
Kobayashi Noritada [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: minor Tags: patch The description for debian-revision-not-well-formed says: N: The debian version part (the part after the -) should consist of one N: to three dot-separated parts: one for maintainer release, two for N: source-NMU, three for binary NMU. The part about the binNMU version numbers is outdated (Bug#437925 reported a similar issue for source-nmu-has-incorrect-version-number and has already been fixed in 1.23.35). Since I don't know whether a newer +bx style binNMU version numbering should be supported in this check, here I provide a patch to just drop support for older x.x.x style numbering from both the regular expression and the description. I've applied the description change for the next version. I think the code is fine; three-part Debian revisions will get a more specific warning a few lines down for being an old-style binary-NMU version number. Thanks! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian: r1109 - in trunk: checks debian
Author: rra
Date: 2008-01-04 07:03:51 +0100 (Fri, 04 Jan 2008)
New Revision: 1109
Modified:
trunk/checks/binaries
trunk/checks/shared-libs
trunk/debian/changelog
Log:
+ [RA] Exclude nsswitch modules from multiple SONAME and package
naming checks.
+ [RA] Exclude nsswitch modules from shlibs file checks.
Modified: trunk/checks/binaries
===
--- trunk/checks/binaries 2008-01-04 05:34:30 UTC (rev 1108)
+++ trunk/checks/binaries 2008-01-04 06:03:51 UTC (rev 1109)
@@ -118,16 +118,18 @@
}
close(IN);
-# For the package naming check, filter out SONAMEs where all the files are
-# at paths other than /lib, /usr/lib, or /usr/X11R6/lib. This avoids false
-# positives with plugins like Apache modules, which may have their own
-# SONAMEs but which don't matter for the purposes of this check.
+# For the package naming check, filter out SONAMEs where all the files are at
+# paths other than /lib, /usr/lib, or /usr/X11R6/lib. This avoids false
+# positives with plugins like Apache modules, which may have their own SONAMEs
+# but which don't matter for the purposes of this check. Also filter out
+# nsswitch modules
sub lib_soname_path {
my (@paths) = @_;
foreach my $path (@paths) {
return 1 if $path =~ m%^(\.?/)?lib/[^/]+$%;
return 1 if $path =~ m%^(\.?/)?usr/lib/[^/]+$%;
return 1 if $path =~ m%^(\.?/)?usr/X11R6/lib/[^/]+$%;
+ return 1 if $path =~ m%^(\.?/)?lib/libnss_[^.]+\.so(\.[0-9]+)$%;
}
return 0;
}
Modified: trunk/checks/shared-libs
===
--- trunk/checks/shared-libs2008-01-04 05:34:30 UTC (rev 1108)
+++ trunk/checks/shared-libs2008-01-04 06:03:51 UTC (rev 1109)
@@ -94,7 +94,8 @@
next if m/^\s*$/o;
if (m/^-- (\S+)\s*$/o) {
- $file = $1; $file =~ s,^(\./)?,,;
+ $file = $1;
+ $file =~ s,^(\./)?,,;
} elsif (m/^\s*SONAME\s+(\S+)/o) {
$SONAME{$file} = $1;
} elsif (m/^\s*TEXTREL\s/o) {
@@ -297,7 +298,7 @@
close VERSION;
chomp $version;
}
[EMAIL PROTECTED] = keys %SONAME;
[EMAIL PROTECTED] = grep { !m,^lib/libnss_[^.]+\.so(\.[0-9]+)$, } keys %SONAME;
if ($#shlibs == -1) {
# no shared libraries included in package, thus shlibs control file should
# not be present
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2008-01-04 05:34:30 UTC (rev 1108)
+++ trunk/debian/changelog 2008-01-04 06:03:51 UTC (rev 1109)
@@ -5,6 +5,8 @@
don't warn about unstripped binaries in ../lib/debug as well.
+ [RA] Allow rpath pointing to /usr/lib/games/package. Thanks, Bas
Wijnen. (Closes: #456318)
++ [RA] Exclude nsswitch modules from multiple SONAME and package
+ naming checks.
* checks/changelog-file{.desc,}:
+ [RA] Don't spell-check lines that include the word spelling.
Thanks, Andreas Hoenen. (Closes: #456515)
@@ -64,6 +66,7 @@
* checks/shared-libs{.desc,}:
+ [RA] New check for version numbers in symbol files. Based on a
patch from Raphael Hertzog. (Closes: #457067)
++ [RA] Exclude nsswitch modules from shlibs file checks.
* debian/control:
+ [RA] Suggest libtext-template-perl, needed for HTML reporting.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
