Re: Indent coding style for lintian
Frank Lichtenheld [EMAIL PROTECTED] writes: I'm also more on the tab side of this argument although I have to confess I normally use the default emacs indentation which is a mixture of tabs and spaces. As long as it is documented feel free to use whatever you like for new code. I've been adding settings for vim and Emacs to each file as I touch them that enforce the tab/space style already prevelant in that file, and using the ones I sent earlier for new code. A manual revision is probably long-overdue. Adding a contributing section there that includes the coding style is probably the best place for it in the long run. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458831: lintian: extra-license-file detects non-license files
Sune Vuorela [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: normal kdelibs-data contains a bunch of docbook snippets used to point to licenses for different licenses and languages. Such one: cat /usr/share/apps/ksgmltools2/customization/en-GB/entities/underArtisticLicense.docbook paraThis program is licensed under the terms of the ulink url=common/artistic-license.htmlArtistic License/ulink./para Currently overridden in kdelibs-data, but I guess it is some kind of bug in lintian. $ grep extra-license-file debian/kdelibs-data.lintian | wc --lines 120 Indeed. Thanks, I cleared up all the docbook stuff for the next release. 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. -- 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
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
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]
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]
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]
Bug#459042: lintian: Should accept python-setuptools as Build-Depends
Vincent Bernat [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: minor Lintian complains about python-setuptools being arch independent when putting it in Build-Depends field. W: pycha source: build-depends-without-arch-dep python-dev Hm, this report is inconsistent. Is python-dev the problem or python-setuptools? (pycha doesn't appear to be in the archive, so I can't easily check myself.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459042: lintian: Should accept python-setuptools as Build-Depends
Vincent Bernat [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: minor Lintian complains about python-setuptools being arch independent when putting it in Build-Depends field. W: pycha source: build-depends-without-arch-dep python-dev Okay, assuming you did mean python-setuptools, I found another package in the archive with this problem and it should now be fixed for the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458896: lintian: Wrong interpreter information w.r.t. pike
Magnus Holmgren [EMAIL PROTECTED] writes: 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. There are no scripts that would be compatible with multiple versions of Pike? 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? I'm going to completely overhaul how script dependencies are handled to try to lift more of the logic into data instead of code, and I'll fix this at the same time. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458896: lintian: Wrong interpreter information w.r.t. pike
Magnus Holmgren [EMAIL PROTECTED] writes: On lördagen den 5 januari 2008, Russ Allbery wrote: There are no scripts that would be compatible with multiple versions of Pike? Hmmm ... well, there probably exist such scripts, but they'd (theoretically) have to be able to work with all packages that can provide /usr/bin/pike, old as well as future, and that can't be guaranteed. Fortunately major Pike releases aren't very frequent... I'm now treating pike like the other versioned scripts, which means that packages that use just /usr/bin/pike require a dependency on one or more of the known pike versions (currently pike7.6 | pike7.6-core | pike7.7 | pike7.7-core). It requires updating the known versions periodically, but the new structure should be much easier to maintain. And presumably if someone uses /usr/bin/pike and has a dependency on pike7.6 | pike7.7, they know what they're doing. The known versions list in lintian is *only* used for allowable dependencies for the unversioned interpreter. If you use /usr/bin/pike8.4 or something else lintian doesn't know about, it will assume that means you need a dependency on pike8.4 | pike8.4-core without needing to know about the version number in advance. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#459293: lintian: partially-translated-question is misleading and not really useful
Christian Perrier [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: normal When a given package has a template that is not completely translated for a given language, lintian issues this warning with: N: If you translate the Choices:' fields in a template, you should N: translate the 'Description:' field as well The maintainer has actually no real influence on this and, anyway, having a debconf templates that's not fully translated is not harmful at all as po-debconf will then not include that language in translations for that template. In short: a debconf template is shown translated only when all its components are translated. This warning is indeed misleading to some maintainer who think they should *remove* incomplete debconf translations in debian/po which is entirely wrong, of course. For all these reasons, I see no real benefit in keeping this lintian warning. Agreed, and removed for the next release. That tag was added in the very first set of debconf checks in 2001-02-14. I'm guessing that the capabilities of debconf have passed it by. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Uploading 1.23.42
I still didn't get completely caught up on new bugs, but given that we're up to 148 lines of changelog from the previous version, I want to get this version into the archive so that it can start shaking out. From past experience with a revision of this magnitude, I almost certainly broke something or missed some additional false positive, and I expect we'll need several releases close together to clean up the fallout. Uploaders support for lintian.d.o, watch file checking, the man page groff warning discussion, and a few other things will have to wait for a later release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458742: lintian: Please test for valid filenames for run-parts
Chris Lamb [EMAIL PROTECTED] writes: Patch attached. Hi Chris, Thank you very much for the patches! What you're doing is very helpful, and I don't want you to stop! But if you have a bit of time in addition, it would save me time if you could also add a new test case for any patch that introduces a new tag. Every tag should have a test case (and if there's something inobvious about when the tag shouldn't trigger, that should also be tested). For this tag, I think we also want to exclude files named .placeholder (maybe any files starting with .) so that we don't get false positives from the cron packages themselves. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458742: lintian: Please test for valid filenames for run-parts
Chris Lamb [EMAIL PROTECTED] writes: Russ Allbery wrote: it would save me time if you could also add a new test case for any patch that introduces a new tag. Revised patch with testcases attached. For this tag, I think we also want to exclude files named .placeholder (maybe any files starting with .) so that we don't get false positives from the cron packages themselves. Agreed; the latter suggestion is reflected in the new patch. Thanks! This looks great; I'll apply this for the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304866: Add warning for build-depends on libsomething not ending with -dev
Chris Lamb [EMAIL PROTECTED] writes: Attaching revised patch with testcases. Looks great. Thank you! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459407: lintian: unusual-interpreter /usr/bin/env
Josh Triplett [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Severity: normal Lintian reports /usr/bin/env as an unusual-interpreter. However, many python scripts use #!/usr/bin/env python to find python on the path rather than assuming a particular location. Lintian should allow /usr/bin/env as an interpreter. Better yet, it should special-case /usr/bin/env and look at the second argument to determine the interpreter, with a whitelist of permissible env-indirect interpreters; to start with, that list should include python. #!/usr/bin/env python is one of the test cases in lintian's test suite, so I'm pretty sure it works in general. lintian's script checking logic already does implement pretty much exactly what you describe. As Chris says, we'll need to see the specific problem that triggered this. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459787: lintian doesn't accept origin and bugs field in binary packages
Raphael Hertzog [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: normal I always get: I: dpkg-dev: unknown-field-in-control bugs I: dpkg-dev: unknown-field-in-control origin Since dpkg-gencontrol propagates Origin and Bugs fields to binary packages, lintian should accept them in binary packages. Thus you need to add them in %known_binary_fields and %known_udeb_fields I think. It's probably worth noting here that there's no specification for either in Policy, so they really are unknown in that sense. That won't stop me from adding them to Lintian's list, since we added Dm-Upload-Allowed and the Vcs-* fields without being in Policy, but we really should document them in Policy as well. I suppose the main reason why they're not there is that for all Debian packages I presume they should have the same value, but I think it would still be worthwhile to specify the syntax. We don't have any other reference document that tries to document all of the Debian package control fields. -- 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: Problem while checking for php-cli
Thomas Goirand [EMAIL PROTECTED] writes:
At the end of this message is the exact message. Lintian thinks that
there is no dependency to php5-cli. That's when using this in my control
file:
php5-cli | php-cli | php4-cli
or if I set only:
php5-cli | php4-cli
The only thing that removes the lintian warning is to set:
php5-cli
only.
Right.
When reading the lintian warning, it makes me feel that I should be able
to use at least php4-cli, maybe php6-cli when it's out, but in fact the
only thing that works is php5-cli only.
The only thing that works is listing PHP packages that are in the archive.
If you list an alternative that isn't in the archive, Lintian will
complain, since it has no way of knowing that alternative would satisfy
your script's requirements.
I'll add an additional explanation to the tag that there's no such package
as php-cli and listing it isn't helpful. (In fact, as long as you include
php-cli in the alternatives, Lintian will *always* complain.)
Would it be possible in the future, that lintian checks that in the
following Depends: statement
a | b | c
there is at least one package of a, b or c, that matches the following
regex:
^php{39}-cli$
instead of the current behavior of lintian?
Lintian doesn't know which of the dependencies in Depends, Recommends, or
Suggests is there for this script. Instead, it applies implication logic
across the entire dependency set. It's not doing regex matching; it's
testing whether all of the package dependencies satisfy a requirement of
php5-cli.
Implementing something like this would require rewriting the package
depencencies before checking the implications to remove alternatives that
are, from Lintian's perspective, uninteresting (such as php4-cli). That
in turn requires doing regex matching and substitution against the
dependencies of the package, which is tricky and fragile.
It's possible, but it's a big change. Without being done carefully, it
would reintroduce all the problems that we had with this check before I
switched it to using the Dep parser.
Handling alternative implications is surprisingly tricky. The code has to
be able to deal with things like:
ruby1.8 [amd64] | ruby1.6 [!amd64]
and be able to figure out that that satisfies a ruby | ruby1.8 | ruby1.6
requirement.
Would it be considered good regarding current version of lintian to do a
lintian override so that my package is also compatible with etch?
I think the best short-term solution would be for me to add php4-cli as a
recognized version for the time being, which means that you shouldn't
change anything about your package. You don't need to add overrides for
bugs in Lintian.
I'll do that for the next release.
PHP command-line scripts are one of only a few versioned interpreters in
Debian that don't provide an unversioned package for scripts that work
with any version to depend on, which is why you're running into this and,
say, the Ruby and Python folks aren't.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460168: lintian: ant needed in clean target
Cyril Brulebois [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: minor Hi, similarly to #457501, I noticed the following for ant: | I: sunflow source: build-depends-without-arch-dep ant But ant is in fact needed in the clean target, at least when used through cdbs's ant.mk: (an equivalent to “make clean”, roughly) lintian tries to bail completely for this tag on packages that use ant. It's too hard to figure out what's needed and what isn't. However, it looks like that logic isn't working in your case for some reason. Currently, lintian looks for: ^include\s*/usr/share/cdbs/1/rules/ant.mk in debian/rules, and it looks like that's the problem and it should be class/ant.mk instead. I'll fix this for the next release of lintian. Thanks for the report! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#460174: lintian: please suggest adding a get-orig-source target when applicable
Cyril Brulebois [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: wishlist Hi, that's a point unknown to or forgotten by some maintainers, when repacking a tarball, one might[*] add a get-orig-source target to create that tarball automatically. Agreed. Checking for the toplevel directory (inside the tarball) ending with “.orig” might also be a nice lintian check to have (that's a “should” from the developers reference). Yes, I think we may already have a bug open about this if dfsg is in the version string. It's also a good idea. It's just a convention, not policy, but it's a fairly persistant one. Reading the devref again, it's is a “must” to provide detailed information about the repack. I guess that encouraging people to script their repack is the right thing to do. I think encouraging it is a good idea, and I don't have a problem saying in the lintian check that if it's not scriptable for some reason, they should still provide a get-orig-source target that prints out an error and then exits with status 2. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#459851: lintian: outputs wrong total count of overrides
Chris Lamb [EMAIL PROTECTED] writes: I'm not sure this is a bug, per se. several-sonames-in-same-package is an info tag, whilst package-name-doesnt-match-sonames is a warning tag. Thus, you only override one = warning tag. Yeah, that's the correct analysis, I think. I would agree if you claimed that this is somewhat misleading. I have attached a patch against SVN trunk (with testcase) which makes the output clearer when you override against a tag of Type: info. Against Cyril's package this outputs: % frontend/lintian ~/temp/cdt.FnP10373/libgraphviz4_2.16-2_amd64.deb N: 1 tag overridden (1 warning, plus 1 useless override) % Well, overriding an info tag isn't useless; it's just that info tags aren't important enough to warrant mentioning that they were overridden for the same reason that they're not shown by default. I think the right fix is probably to keep the current behavior if -I wasn't given, but if -I was given, add the number of info tags overridden to the summary as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459851: lintian: outputs wrong total count of overrides
Cyril Brulebois [EMAIL PROTECTED] writes: On 11/01/2008, Russ Allbery wrote: Chris Lamb [EMAIL PROTECTED] writes: I'm not sure this is a bug, per se. several-sonames-in-same-package is an info tag, whilst package-name-doesnt-match-sonames is a warning tag. Thus, you only override one = warning tag. Yeah, that's the correct analysis, I think. I also thought of that, but reading the manpage, it is about the *total* count, that's why I was thinking that it needed at least some clarification. Yeah, the man page is lying to you. :) I think the right fix is probably to keep the current behavior if -I wasn't given, but if -I was given, add the number of info tags overridden to the summary as well. Agreed. I'd also suggest getting rid of the “total” word in the manpage, “count” is enough. (Maybe also adding some words explaining that this count depends on the options that are passed, like -I, but that would a bit overkill, I believe, once that your “right fix” is implemented.) Hm, or we could list the total including info tags and only mention the info overrides explicitly if -I is given. So without -I, you'd get something like: N: 2 overrides (1 warning) That probably wouldn't be any less confusing, though. I'd like to ahve the total remain, so maybe we should just always list the info total as well, whether -I is included or not. N: 2 overrides (1 warning, 1 info) (Completely separately, I'm really questioning the utility of the two tags you're overriding, particularly the info tag, and they may just go away or be significantly modified in a later version of lintian.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#459787: lintian doesn't accept origin and bugs field in binary packages
Raphael Hertzog [EMAIL PROTECTED] writes: On Tue, 08 Jan 2008, Russ Allbery wrote: It's probably worth noting here that there's no specification for either in Policy, so they really are unknown in that sense. That won't stop me from adding them to Lintian's list, since we added Dm-Upload-Allowed and the Vcs-* fields without being in Policy, but we really should document them in Policy as well. Note that Breaks suffers from the same problem. Breaks will be in the next Policy release. I should also say that those should also be fixed IMO: I: dpkg source: non-standard-arch-in-source-relation kfreebsd-i386 [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]] I: dpkg source: non-standard-arch-in-source-relation kfreebsd-amd64 [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]] kfreebsd-i386, kfreebsd-amd64, armel are unofficial architectures which are mentioned in many cases. That's the definition of non-standard architecture. Maybe the tag should go away completely, but assuming that one buys the reason for having the tag at all, it is correct in this case. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460499: lintian: No need to warn about missing short-description LSB header in init.d scripts
Petter Reinholdtsen [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.41 Now that the LSB headers in init.d scripts is more used, it has become obvious that the lintian warning about missing short-description is not needed. As far as I know, there is nothing using this header, and quite a lot of scripts are missing it. It is only nice to have, and do not deserve a warning on its own. Here is an example warning from the list of lintian messages on the web: W: chrony: init.d-script-missing-lsb-keyword /etc/init.d/chrony short-description Because of this, I recommend dropping the warning. Do you think we should drop it completely or just reduce it to info? I think having a description is rather nice and may help figure out where an init script abandoned by some previous package came from without having to do as much research. It still feels like a best practice thing even if it isn't used by software. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459787: lintian doesn't accept origin and bugs field in binary packages
Raphael Hertzog [EMAIL PROTECTED] writes: On Sat, 12 Jan 2008, Russ Allbery wrote: I should also say that those should also be fixed IMO: I: dpkg source: non-standard-arch-in-source-relation kfreebsd-i386 [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]] I: dpkg source: non-standard-arch-in-source-relation kfreebsd-amd64 [build-depends: libselinux1-dev (= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]] kfreebsd-i386, kfreebsd-amd64, armel are unofficial architectures which are mentioned in many cases. That's the definition of non-standard architecture. Maybe the tag should go away completely, but assuming that one buys the reason for having the tag at all, it is correct in this case. I'd expect that those kind of checks are made to catch typo in arch names for example. But not valid arch names which have not yet been integrated. No, really, I promise, this check is designed to catch exactly what it's catching. :) The tag you're thinking of is invalid-arch-string-in-source-relation, which is an error and not info. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460625: Check for python build-deps doesn't allow packages relying on specific versions
Loïc Minier [EMAIL PROTECTED] writes: On Mon, Jan 14, 2008, Russ Allbery wrote: It sounds like, from your analysis, that the verioned dependencies also need to be permitted for Python (namely python2.4 | python2.4-dev | python2.5 | python2.5-dev) and if that were added, that would resolve your issue. Does that sound right? That's also the conclusion I come to, yes. It's going to be a pain to maintain for you though. It needs updating each time we get a new Python, but this is far from the only thing in Lintian that already requires that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#461978: lintian: spurious Perl warnings with --unpack
Håkon Stordahl [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: minor Tags: patch Use of the --unpack action with Lintian causes Perl to print some harmless, but a bit annoying, warnings: $ lintian --lab /tmp/lab --setup-lab $ lintian --lab /tmp/lab --unpack lintian_1.23.42_all.deb Use of uninitialized value in addition (+) at /usr/bin/lintian line 1427. Use of uninitialized value in addition (+) at /usr/bin/lintian line 1427. I can't duplicate this. The same commands produce no warnings for me. Regardless, though, the code that produces those warnings shouldn't even be running when the action isn't --check, which I'll fix. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#462456: lintian: Please consider testing if files in -dbg packages retain Dynamic Section entries
Neil Williams [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: wishlist See #462007 - I have come across a non-obvious problem in the use of -dbg packages using dh_strip where, if a .install file exists for the -dbg package, dh_install copies the unstripped object into the -dbg build directory. When dh_strip --dbg-package=libfoo-dbg is then called, it silently omits the file from the call to objcopy --only-keep-debug (to prevent an objcopy error), resulting in an unstripped object file being retained in the -dbg package that has a complete (and fully functional) copy of the library embedded inside - as shown by the presence of a full Dynamic Section under objdump -p. Without the .install file, dh_strip takes care of copying the debug symbols into place directly - no .install command is actually needed. Some people intentionally put debugging builds of their libraries into the -dbg package instead of detached debugging symbols. I think this test might give false positives for that case. (Or are such library builds not seupposed to go into /usr/lib/debug?) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451668: Reply not resent to maintainer
Jordà Polo [EMAIL PROTECTED] writes: A few days ago I replied[1] to a lintian bug that was already closed (#451668). For some reason the message wasn't sent to the maintainer, or at least it doesn't appear in the mailing list archive[2]. Yeah, the mailing list seemed to lose a bunch of mail recently, including new bugs. I'm not sure what to make of that. I'm not sure my reply is worth a new bug report, and I don't want to duplicate information unnecessarily either. But since it is hardly visible as it is, I just wanted to make sure that at least someone was aware of it. Thank you! My personal feeling is that binaries that support games (level editors, level converters, data manipulators) should also go into /usr/games. Rationale: the purpose of the /usr/games split is so that system administrators can easily partition off game-related files, delete them en masse if need be, not put game binaries on some user paths, etc. The supporting binaries for games are in that sense even less part of the main system than the game itself; if the game itself is relegated to /usr/games, it doesn't make sense to me to give its level editor a higher visibility than the game. It's much murkier when a game also ships a general utility, although that's also a rather odd case and may even be a case where the general utility should be in a separate package, since installing a game to get a general utility is very unintuitive. For those who didn't see the original message, here's the included list: eboard /usr/bin/eboard-config - get information about the installed eboard exult /usr/bin/expack - manipulate flex files /usr/bin/exult_studio - world editor /usr/bin/ipack - manipulate flex files /usr/bin/shp2pcx - extract images from a shape /usr/bin/splitshp - split shape files into frames /usr/bin/textpack - pack/unpack flex files containing text /usr/bin/ucc - usecode compiler /usr/bin/ucxt - usecode disassembler fortune-mod /usr/bin/strfile - create a random access file for storing strings /usr/bin/unstr - dump strings in pointer order jumpnbump /usr/bin/jumpnbump-pack - create levels /usr/bin/jumpnbump-unpack - unpack levels /usr/bin/jumpnbump-gobpack - convert .gob to .pcx neverball /usr/bin/mapc - map compiler pydance /usr/bin/findbpm - calculate the beats per second of a song pyracerz /usr/bin/pyracerz - symlink to /usr/games/pyracerz xconq /usr/bin/imf2x - translates image families into bitmaps /usr/bin/x2imf - converts bitmap images into portable image family /usr/bin/ximfapp - image viewer I'm pretty comfortable with saying that all of those should really be in /usr/games and not in /usr/bin, with the possible exception of the xconq and exult utilities depending on how widespread use of those file formats is outside of that particular game, and fortune, which is a weird special case and arguably doesn't belong in games at all. (The neverball map compiler has an unfortunately generic binary name that I'd probably change, were I maintaining the package.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#462586: lintian: Please don't no-description-in-changes-file for source-only .changes
clone 462586 -1 reassign -1 debian-policy retitle -1 Description doesn't make sense (and dpkg no longer generates it) for source-only *.changes files severity -1 normal thanks Cyril Brulebois [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: wishlist since dpkg-dev is moving quite quickly these days, I postponed its upgrade, and only hit today the following: | E: graphviz_2.16.1-1_source.changes: no-description-in-changes-file Since dpkg/1.14.16, we have: | * Some code refactoring on dpkg-genchanges and bug fixes in the generation | of the Description: field. As a result, source only uploads will no more | have Description fields. I presume it'dbe safe to turn off this check when checking a source-only upload (if you don't detect source-only uploads yet, I guess that the /_source.changes$/ pattern should do the job. Policy 5.5 says that Description is mandatory for all *.changes files, which is why the lintian tag. However, I agree that Description doesn't make much sense for source-only uploads, since there are no individual package descriptions in that case to lift into it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463281: lintian: tclsh-script-but-no-tclsh-dep and wish-script-but-no-wish-dep don't test for all Tcl/Tk packages
Sergei Golovan [EMAIL PROTECTED] writes: These checks can't be sufficient anymore. There are two new packages tcl8.5 (which includes /usr/bin/tclsh8.5) and tk8.5 (includes /usr/bin/wish8.5) which can be used for invoking tclsh and wish scripts respectively. The version of lintian against which you're reporting this bug is already aware of version 8.5. Also, packages tcl and tk are added. They don't contain any files but depend on default tclX.Y and tkX.Y packages (currently tcl8.4 and tk8.4). So, a package with tclsh script can depend on tcl, and a package with wish script can depend on tk. Added. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463281: [SPAM] - Re: Bug#463281: lintian: tclsh-script-but-no-tclsh-dep and wish-script-but-no-wish-dep don't test for all Tcl/Tk packages - Bayesian Filter detected spam
Sergei Golovan [EMAIL PROTECTED] writes: On 1/30/08, Russ Allbery [EMAIL PROTECTED] wrote: Sergei Golovan [EMAIL PROTECTED] writes: These checks can't be sufficient anymore. There are two new packages tcl8.5 (which includes /usr/bin/tclsh8.5) and tk8.5 (includes /usr/bin/wish8.5) which can be used for invoking tclsh and wish scripts respectively. The version of lintian against which you're reporting this bug is already aware of version 8.5. My bad. I haven't noticed that versions on lintian.debian.org and in sid differ. Yeah, I really need to find time to update it. I can hardly wait for gluck to move to etch, which will make that much easier. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463474: lintian: Please check doc-base Section field for allowed values
Kevin B. McCarty [EMAIL PROTECTED] writes: According to the instructions shipped with the doc-base package, file /usr/share/doc/doc-base/doc-base.txt.gz , paragraph 2.3.2.1, the Section field in a doc-base file should use the Debian menu sections: _Section_ Section where the document belongs; this should follow the sections outlined in chapter 3.5 of Debian Menu Policy, which can be found in the /usr/share/doc/menu/html (file:///usr/share/doc/menu/html/ch3.html#s3.5) directory. Required field. Since the allowed menu sections have recently changed (and lintian now thoughtfully checks for this), it stands to reason that maintainers should also be reminded to change the Section fields in their doc-base files, ideally with the transition being completed pre-Lenny. Therefore, would it be possible to have Lintian run the same check on doc-base file Section fields as it does on menu file section fields? I know that this would certainly help me out! X-Debbugs-CC'ed to the doc-base maintainer in case he wants to comment. Note, if it was *not* the intention to have doc-base follow the menu policy transition, please reassign this bug to doc-base and retitle to doc-base: should explicitly list allowed values for Section field. The main reason why I didn't do this is that there was a lot of controversy and discussion on debian-devel about using the menu categories for doc-base recently, and I was wondering if that would reach some other conclusion. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463474: lintian: Please check doc-base Section field for allowed values
Kevin B. McCarty [EMAIL PROTECTED] writes: Somehow I must have completely missed that discussion. Thank you for the pointer. I guess what happens next is in the hands of doc-base maintainer then? That would be my preference. If he says that we'll continue using the menu categories, I'm happy to change lintian accordingly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463138: lintian: package-contains-empty-perl-directory and Perl 5.10
Niko Tyni [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.43 Severity: wishlist Please consider a note about the unconditional rmdir issue in the package-contains-empty-perl-directory description. Something like this: This package installs an empty /usr/lib/perl5 or /usr/share/perl5 directory. This is an artifact of ExtUtils::MakeMaker and isn't harmful, but it's messy. It's preferrable to remove the directory the package doesn't use (/usr/share/perl5 for binary Perl modules and /usr/lib/perl5 for pure Perl modules) in debian/rules after running make install. + + Note that ExtUtils::MakeMaker has been fixed in Perl 5.10, so make + sure not to fail if the directory does not exist in the first place. + One implementation can be found in the dh-make-perl debian/rules templates. See #458143 for some background to this. I'm going to just remove this tag from lintian entirely. Given that Perl 5.10 is coming soon and the empty directories don't cause problems, just untidiness, I think it's better to have maintainers just leave the directories for right now rather than possibly introducing FTBFS problems by trying to fix it. The Debian Perl Group has good internal procedures for testing things and can fix this for our packages, but since the real bug is in Perl, I think the average maintainer is best off just ignoring it until the bug is fixed there. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463913: lintian: Miscounts line length when unicode characters are involved
Andrew Pollock [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: normal As best I can determine, Lintian was complaining about a changelog line being too long, when it was 77 characters long, but it contained three unicode characters in it. I'm guessing it was counting the unicode characters as two characters each. Yup, it was indeed. Will be fixed in the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464026: [checks/scripts] Sync bashism tests with checkbashisms
Adam D. Barratt [EMAIL PROTECTED] writes: As discussed recently, please find attached a patch (against lintian and devscripts SVN) to checks/scripts that adds the bashism tests that devscripts's checkbashisms performs but lintian does not. Thank you! You beat me to doing the merger. One question, though: + 'echo\s+-[e]', # echo -e + 'exec\s+-[acl]', # exec -c/-l/-a name + '\blet\s', # let ... Shouldn't these be prefixed with (^|\s+) instead of \b or nothing to not catch things like echo echo -e (as odd as that might be)? We do run the risk of missing cases where people put the statement on the same line as an if statement or the like, but I think it makes sense to err on the side of conservatism. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464026: [checks/scripts] Sync bashism tests with checkbashisms
Adam D. Barratt [EMAIL PROTECTED] writes: The first two certainly should be prefixed by something to avoid them matching strings that happen to end in echo -e. I've updated checkbashisms to do so for all three. As far as I can see that won't stop echo echo -e matching, however. I was proposing using: '(?:^|\s+)echo\s+-e',# echo -e '(?:^|\s+)exec\s+-[acl]',# exec -c/-l/-a name '(?:^|\s+)let\s',# let ... -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464026: [checks/scripts] Sync bashism tests with checkbashisms
Adam D. Barratt [EMAIL PROTECTED] writes: That's what I've changed checkbashsims to use. Unless I'm missing something (which I'm more than happy to have pointed out :) echo echo -e matches \s+echo\s+-e as the expression isn't (in that case) anchored to the start of the line. Oh, d'oh, you're entirely correct. Sorry about that. I misread that regex. Hm, that's more aggressive than I expected, but since I've not gotten any bug reports, I guess I'll leave it and see if anyone complains. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464461: lintian: Wrongly getting a spelling error
Nelson A. de Oliveira [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.43 Severity: minor Hi! With this README.Debian file http://people.debian.org/~naoliv/misc/README.Debian lintian is giving two warnings: W: audtty: spelling-error-in-readme-debian dbus D-Bus W: audtty: spelling-error-in-readme-debian dbus D-Bus I don't know if it is possible to detect cases like this, were there is a script called dbus.sh Also, it isn't getting the wrong (I think) DBUS on the end of the file. Shouldn't lintian says that it's also wrong? It's actually not complaining about dbus.sh at all. It's complaining about DBUS, as you mention, and (due to a bug), the correct D-Bus. It's also putting in the tag the transformed version of the word instead of the original as found in the text, which unfortunately is even more confusing if not done that way. I'm going to drop this particular correction from the non-case-sensitive corrections (and fix the bug that caused it not to recognize D-Bus). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464511: detect a fully vaild .po file as non-valid
Patrick Winnertz [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.42 Severity: normal While building the newest debian-edu-install I've detected that lintian raises a warning about: misnamed-po-file debian/po/nds.po Actually this is a fully valid .po file, so there seems to be a bug in lintian. What we were told was that all language codes are two letters followed possibly by an underscore and two more letters (in capitals). If this isn't true, I'd be happy to change lintian, but I know nothing about this whole area, so I really need some sort of canonical documentation or i18n expert to tell me what to do. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464626: missing-dependency-on-perlapi: false positives
gregor herrmann [EMAIL PROTECTED] writes: AFAICS the test in checks/binaries tries to match the Depends: line against /(?:^|,)\s*perlapi-[\d.]+(?:\s*\[[^\]]+\])(?:\s*,|\z)/ where the [..] part seems a little strange to me. At a first glace it could just be left out IMO. It was, er, supposed to be optional. *sigh*. Fixed now. It catches architecture restrictions to allow for perlapi-5.8.8 [i386]. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464709: lintian: Something wrong with checking for python build-depends
Joerg Jaspert [EMAIL PROTECTED] writes:
Something seems to be wrong with python in Build-Dependencies.
Yeah,
my $python_depend = 'python | python-dev | python-all | python-all-dev'
. join (' | ', map { python$_ | python$_-dev } qw(2.4 2.5));
doesn't actually work -- python-all-devpython2.4 is not a common package.
*heh*. Fixing now. I'll upload another version later today.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464775: lintian: false positive about debconf module loading
Manoj Srivastava [EMAIL PROTECTED] writes:
Lintian says:
W: mailagent: postinst-does-not-load-confmodule
But the postinst does:
##
my $have_debconf = 0;
eval {require Debconf::Client::ConfModule;};
if ( ! $@ )
{
$have_debconf++;
import Debconf::Client::ConfModule ':all';
}
##
The postinst either uses debconf, if available, or it prompts by
itself (since the prompting predates debconf). Does lintian presume
that all postinst scripts are shell scripts?
No, it was just expecting use and didn't know about require. I've taught
it about require and the fix will be in the bug-fix release of lintian
that will probably be uploaded this evening.
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]
Re: Another raw idea for lintian check: variable substitution in debconf templates
Christian Perrier [EMAIL PROTECTED] writes:
Yet another idea popping up in my mind. I'm in a lintian mood today..:)
Yay! :)
Some debconf templates use variable substitution (along with debconf's
SUBST command) to incorporate context-variable text in debconf
templates.
Description: Do you want to erase disk ${DISK}?
Blah blah blah
Translators MUST keep these variables unchanged in their translation
and a very common mistake is translating them. French example:
Voulez-vous effacer le disque ${DISQUE}?
The result will be the variable popping up untranslated which is very
disturbing and confusing for users (particularly in that case!).
In D-I spellchecker, we added such check for bad variable
substitution and it catched many such errors.
Sure, that sounds like a good idea to me. Should we trigger on anything
in a lintian template that looks like ${DISK}? Would $DISK also be valid,
or are the curly braces required?
I'm sorry for not being technically able to provide the appropriate
patch to lintian for this but that could deserve some attention.
I assume that something like the following pseudocode would work:
foreach pofile in debian/po/*.po
foreach msgid, msgstr in pofile
vars_needed = find_variables(msgid)
vars_found = find_variables(msgstr)
if (not empty(msgstr) and vars_needed != vars_found)
tag 'variable-mismatch-in-translation', pofile, line
end
end
end
--
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: Merge tags for VCS'?
Frank Lichtenheld [EMAIL PROTECTED] writes: While taking a look at #464837 (which is about source packages) I noticed that checks for mercurial files are also missing for binary packages. Before I add yet another tag I wanted to ask whether it wouldn't be better to merge the tags for the different VCS', like so Yeah, that looks good to me. They're broken out for source packages since they offer some useful advice in a few cases, but in binary packages the text of all the tags is identical. Actually, now that I look at it, the diff-contains-* tags could also be merged (but the source-contains-* tags are a bit different). May not be worth the effort, though. -- 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: Test suite failure
Frank Lichtenheld [EMAIL PROTECTED] writes: While doing some lintian work today (yay!) I noticed the following failure that doesn't seem to have anything to do with my changes, and which is an area I really am not motivated to debug ;) Known issue? I was accidentally testing a bug in debhelper. Committing a fix in a moment. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464837: should warn about merciurial files
Chris Lamb [EMAIL PROTECTED] writes:
What this patch doesn't do is apply the same cleanup to the
diff-contains- FOO-control-{file,dir} tags. Is this wanted?
Currently, we provide some extra advice in that case, such as how to
generate a tree without those files. Whether that advice is sufficiently
useful to warrant the separation, I'm not sure. I considered merging them
when I restructured how the code worked and decided not to, but not for
any strong reasons.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464992: lintian: Copyright false positive
Adam C Powell IV [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Greetings, My package petsc is flagged by the copyright-without-copyright-notice check, but has the following line in its copyright file: (C) COPYRIGHT 1995-2004 UNIVERSITY OF CHICAGO This is a false positive, as this line seems to satisfy all of the requirements: copyright, date, holder. Is the check case-sensitive such that it misses the all-caps COPYRIGHT? Yes, sorry, my mistake. The check was supposed to be case-insensitive. Will be fixed shortly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464837: should warn about merciurial files
Holger Levsen [EMAIL PROTECTED] writes: package: lintian version: 1.23.44 Hi, lintian doesnt warn about left over mercurial files in the source package, like it does with svn or cvs files. The following files remained unnoticed in my source package: .hg_archival.txt |2 .hgignore | 29 .hgtags | 10 We intentionally don't warn about files like .hgignore in a source package since they're normally intentionally shipped with the upstream source or used by the Debian developer in their debian directory. They're useful version control metadata for anyone else who wants to reimport the package into a version control system. I'm not sure about .hg_archival.txt and .hgtags, though. We do currently warn about arch inventory files, so if this is a similar case, I can see adding a similar warning about them. But I'm hesitant to do so without a clearer understanding of what the files are for and how someone would normally avoid including them in the package. Note that dpkg-source does not currently filter out any of these files when the -i option is used, only the .hg metadata directory, so the instructions for how to avoid them in diffs used for other files in the source package wouldn't be accurate. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465132: outdated-autotools-helper-file: Should refer to autotools-dev README
Daniel Leidert [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: wishlist The long description for outdated-autotools-helper-file should IMO refer to the README of autotools-dev for possible solutions to fix this lintian warning. There was discussion recently at debian-mentors: http://lists.debian.org/debian-mentors/2008/02/msg00210.html Because of this I think, referencing the README would help to explain the warning. Yeah, I added that when I saw the debian-mentors discussion, but you had no way of knowing that and I definitely appreciate the bug report in case I'd not seen it. Will be there in the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253012: [checks/scripts] check all /bin/sh scripts for bashisms
Raphael Geissert [EMAIL PROTECTED] writes: Will this feature be implemented anytime soon? I don't know. I mentioned in debian-devel roughly what I think needs to happen for it to be implemented, namely: What needs to happen from the lintian perspective is to refactor check/scripts to pull the code for checking for bashisms into a module, and then apply that same code to check other shell scripts and to the (detabbed) shell constructs in debian/rules. Getting the interface to the module right may be a little tricky. When I have time to work on lintian, I generally fix all bugs with a severity higher than wishlist first and then pick a few wishlist bugs at random that I feel like working on and tackle them. I don't have any plan in advance for when I'm going to work on any particular bug. It's fairly certain that this bug won't be fixed by me within the next couple of weeks since I won't have much time to work on lintian for that time period. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465258: lintian: copyright-without-copyright-notice should accept line breaks
Michael Meskes [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: wishlist Running lintian on kdebluetooth gives (among others) this message: W: kdebluetooth: copyright-without-copyright-notice However, the copyright file says: Copyright: (C) 2007 Novell, Inc. (C) 2007 Tom Patzig [EMAIL PROTECTED] ... Looks fine to me except that there is a CR involved. It currently handles a date appearing in that situation but not (C) followed by a date. That's a pretty simple fix; I'll add that for the next version. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465192: lintian: Please warn on documentation referring to /usr/doc
Guillem Jover [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: wishlist Hi, Even if we've completed the /usr/doc to /usr/share/doc transition some time ago, there's still documentation in Debian referring to /usr/doc. Those should probably be fixed. On my system, this crude check: $ find /usr/share/doc -type f| grep -v [Cc]hangelog | xargs zgrep /usr/doc gives some hundred hits. There's few false positives though, like the policy upgrade-checklist.txt, I guess those could be excluded. We do already check man pages, and adding README.Debian makes sense to me. Going beyond that gets pretty hairy for possible false positives, but README.Debian at least should be fine. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286842: lintian: Avoid false positives
Felipe Sateler [EMAIL PROTECTED] writes: Package: lintian Followup-For: Bug #286842 Is this working correctly? Take this from the csound package I'm preparing (not in the archive yet): Copyright notices: Csound is copyright (c) 1986-1992 by the Massachussetts Institute of Technology 1991-2008 by Barry Vercoe, John ffitch and others. CsoundAC (formerly CsoundVST) is copyright (c) 2001-2008 by Michael Gogins. The csound Manual is copyright (c): 2003 by Kevin Conder 2004-2005 by Michael Gogins This is causing lintian to warn about copyright-without-copyright-notice It doesn't like the interposed (and meaningless) (c) in the case where the copyright is split across multiple lines. I'll try to make it better about recognizing this, but the second example in particular gets more and more annoying to detect as more punctuation and newlines are added. It's much easier if the debian/copyright file just has the official legal copyright notices on lines by themselves. The more work that goes into moving things around, adding punctuation and newlines, and whatnot, the harder it is to detect. In other words, better would be: Copyright 2003 by Kevin Conder Copyright 2004-2005 by Michael Gogins However, in general you want to copy the upstream notices verbatim, and I know that these two desires are in tension and upstreams use notices like you have above. The cases above should be possible to adapt for. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286842: lintian: Avoid false positives
Felipe Sateler [EMAIL PROTECTED] writes: What bothers me is that although I have a line blah is copyright by joe, lintian is still complaining. After all, the different modules have different copyrights. I see that the regex is not case insensitive and thus checks for Copyright but not copyright, which would have avoided the warnings in my case. Ah, yes, I missed that you also had that line. Yes, the fix for the other bug already reported will take care of that. For the other cases, can't perl be made to read more than one line per pattern? It can, but that also leads to false negatives. I think it's better the way that it is, once the case insensitivity is fixed and it's a bit more accepting about (c) bits when there's an intervening newline. -- 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: Some fixed warnings still showing up on lintian.d.o
Christian Perrier [EMAIL PROTECTED] writes: Hell dear lintian maintainer(s), I'm currently working to fix debian-changelog-file-uses-obsolete-national-encoding. (a lenny release goal) My work tool is, among others, the http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html page I recently NMU'ed several packages but some of them still shown up on the page, namely slashem and xcin2.3 Is there a reason for this which I would be unaware of? It looks like a lintian problem. It's not picking up the latest versions of those packages for some reason. I think something went wrong with the lintian runs a few days back. Rather than try to poke at it too much, I've just updated lintian to the latest version on lintian.d.o and started a full archive run. It should be fixed (with various other improvements in the reports) by sometime tomorrow. -- 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: dfsg/ds/etc versioning
Paul Wise [EMAIL PROTECTED] writes: Does lintian check for and warn about versions like 1.2.3.dfsg1? The reason it should is this: 1.2.3 1.2.3+dfsg1 1.2.3.4 1.2.3.dfsg1 My NM found that more packages use the dot variant (621) than use the + variant (263). I also wonder if lintian checks for dsfg (vs dfsg) in the version? One package on i386 currently would trigger this warning. Should I have my NM file patches about these things? Currently there are no fixes for anything in this area (also including checking for the repackaged source directory in the tarball and ideally checking the watch file for version mangling as well, although there are no watch files at all at present). I'd be happy to accept patches for this. -- 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: web pages broken?
Thomas Bushnell BSG [EMAIL PROTECTED] writes: The lintian.debian.org webpages seem to be broken. Is this a temporary condition? Yes, they're being regenerated now. The first pass on web page generation ran afoul of a bug in the current version of lintian (which will be fixed in the next release). It moves backwards from Z to A and it's up to Fr, so it shouldn't be too much longer. -- 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: checks/scripts / checkbashsims updates
Adam D. Barratt [EMAIL PROTECTED] writes:
Please let me know how you'd prefer to handle these, and any such issues
that arise in future. I'm more than happy to simply provide a list (as
below), send patches to the list or file bugs against lintian with
patches.
Either patches to the list or bugs against lintian with a list would be
ideal for me.
The first issue is from the checkbashisms side:
'(?!\$)\(\(', # '((' should be '$(('
This will also match constructs such as if ((foo || bar) baz). I've
tightened the expression in checkbashisms SVN to be '(?!\$)\(\(.*\)\)'.
Done likewise in Subversion for lintian.
The second issue that was highlighted is the check for arguments being
passed to scripts that are sourced (i.e. . foo bar). There are a
number of constructs that the current check flags, which so far as I can
tell are all legitimate:
. ${sysconfdir}/pop3d; \
. ${sysconfdir}/pop3d-ssl ; \
. `dirname $0`/guilt
I've modified the check to:
if (not $found and m/^\s*(\.\s+[^\s;]+\s+([^\s]+))/) {
which allows all of the above. The only problem I've found with it is
that constructs such as
. `foo bar` `foobar baz`
aren't flagged, but IMHO that's the lesser of two evils.
I assume that you mean [^\s;\`] here instead of only ;. Done similarly in
lintian.
Finally, script_is_evil_and_wrong() allows ;exec foo but not ; exec
foo. I'm assuming this was a simple oversight, as the two forms are
equivalent.
Added \s* after ; in the regex. 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]
Re: Some fixed warnings still showing up on lintian.d.o
Christian Perrier [EMAIL PROTECTED] writes: Quoting Russ Allbery ([EMAIL PROTECTED]): Forbidden You don't have permission to access / on this server. Apache/1.3.33 Server at lintian.debian.org Port 80 This works correctly now that the scan of the archive is finished. OK, I was suspecting something like that but I didn't imagine this would take so long..:-) The old web pages would have been available while it worked, if I hadn't screwed up. Or if I'd thought to regenerate them while lintian chugged away (although by the time I realized I'd accidentally deleted the pages, it was mostly done). Sorry about that. It takes about a day and a half for poor gluck to make it all the way through the i386 archive. Hmmm, that actually explains why lintian.d.o sometimes reports that it didn't see any change from one day to anotherwhich I noticed while working on this. So, I now have to find out what updates the archive on gluck and nag some people about this to happen on a regular basis. I should similarly figure out how to request that Apache be reloaded, since apparently just using an .htaccess file for the redirect of the tags URLs (which I thought would work) doesn't. The new version of lintian now installed on lintian.d.o will at least tell you what version of the package it checked if you go to the maintainer page, which helps a lot in figuring out what's going on with this sort of thing. It will also tell you if anyone is overriding a tag. -- 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: Some fixed warnings still showing up on lintian.d.o
Christian Perrier [EMAIL PROTECTED] writes: Quoting Russ Allbery ([EMAIL PROTECTED]): Rather than try to poke at it too much, I've just updated lintian to the latest version on lintian.d.o and started a full archive run. It should be fixed (with various other improvements in the reports) by sometime tomorrow. Well: http://lintian.debian.org/ Forbidden You don't have permission to access / on this server. Apache/1.3.33 Server at lintian.debian.org Port 80 This works correctly now that the scan of the archive is finished. http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html This will work correctly as soon as the Apache server on gluck is restarted to pick up the redirect. The new canonical URL is: http://lintian.debian.org/reports/tags/debian-changelog-file-uses-obsolete-national-encoding.html Clicking on the package will show the package's full lintian report and the package version, which reveals that, for example, xcin2.3 is version 2.3.04.3-3.1, indicating that lintian.d.o hasn't seen your update yet. And that: gluck:/org/ftp.debian.org/ftp/project/trace cat ftp-master.debian.org Wed Feb 13 08:00:02 UTC 2008 is because the archive on gluck hasn't been updated since you uploaded your package. Why that might be, I have no idea. -- 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: checks/scripts / checkbashsims updates
Adam D. Barratt [EMAIL PROTECTED] writes:
I didn't, but it works better, so I do now. :-) The final [^\s]+ group
alwo wants to be [^\s;]+ or
. ${sysconfdir}/pop3d-ssl ; \
is still flagged. (Adding ` to that group didn't seem to make any
difference to my test expressions).
Ah, yes, thanks. That change has now also been made in lintian.
--
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: checks/scripts / checkbashsims updates
Adam D. Barratt [EMAIL PROTECTED] writes: Sorry to be a pain, but we've tightened this further in svn to '(?![\$\(])\(\(.*\)\)' so as not to match constructs such as progress_size=$(((100 - $PROGRESS_STATE) / 3)) What *is* this construct trying to catch, anyway? dash supports things like $((4 + 5)), and if the above is also okay, I'm not sure when this would not be a false positive. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466714: bogus advice in copyright-without-copyright-notice
Peter Eisentraut [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: normal Lintian says: N: A N: copyright notice must consist of Copyright, Copr., or the Unicode N: symbol of C in a circle followed by the years and the copyright N: holder. I don't believe this is true. It is just as valid to say, This software was written by Joe Hacker and you can use it according to the following conditions. It's valid to say that, but it isn't a copyright notice. According to the relevant international conventions on copyright matters, copyright exists independent of it being mentioned explicitly, as you appear to believe. No, that's not what I believe, nor is that what the lintian tag description says. You are not required to supply a copyright notice for a work to be copyrighted. The only purpose of a copyright notice for the copyright holder is, in some jurisdictions, to eliminate a defense of ignorance and to increase the possibility of statutory damages. However, *if* you want to provide a copyright notice, *then* you have to provide a notice in that format, and notices in other formats do not constitute a legally valid copyright notice. Please supply the reasons for your claim. http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html as referenced by http://ftp-master.debian.org/REJECT-FAQ.html In that message, from Joerg in his capacity as ftp-master: | Your debian/copyright file must contain the following information: | | - The author(s) name | - The year(s) of the copyright | - The used license(s) | - The URL to the upstream source Going from that to saying that debian/copyright should include a correct copyright notice is a bit of a leap, but not much of one, as a valid copyright notice is the best way of satisfying the first two requirements. I'll clarify the long description to make it more obvious that this is a Debian-specific requirement, not something required for a work to be considered copyrighted. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466665: lintian: menu-command-not-in-package should not warn about the use of su-to-root
Paul Wise [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: normal Currently the menu-command-not-in-package warning is output when the menu file uses su-to-root. It should not do so, because su-to-root is available in the menu package, so it will be available to everyone who uses the menu item. There's code in lintian specifically to not do this, and running lintian on two packages I have installed locally that use su-to-root in menus (magicfilter and alsa-utils) doesn't produce that tag. Could you point me at the package where you're having this problem? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466714: bogus advice in copyright-without-copyright-notice
Peter Eisentraut [EMAIL PROTECTED] writes: If the author of the work is an individual, then the copyright exists some number of years past his lifetime. If the author doesn't write Copyright 2007 in his files, then I can't make that up. Moreover, the exact years really don't matter much. Either the copyright exists, and then we are presumably granted a suitable license, or it doesn't, in which case we can use the work anyway. This is a fairly rare case and other Debian Developers have in the past gone back to the upstream author and asked for a copyright notice in this case. Also, an override may be appropriate here for the case where that really isn't possible. Alternately, you can persuade Joerg to clarify what the ftp-master requirements are. I really want lintian to check based on what he's accepting or rejecting, and right now the reject FAQ is pretty explicit that you must list the copyright date and author. The other part that is not really clear in the sources you cite is author vs. copyright holder. I don't think it can be very successful to attempt to squeeze the reality of authorship rights into a uniform copyright statement. We need to explain to the user which rights he has and how those rights came about, but there is no need to beat that into a common form so lintian can parse it. On this, I guess I just disagree on the cost/benefit tradeoff. What lintian is asking for has been common practice on debian-mentors and there were two separate wishlist bugs filed asking for this check. It catches a lot of broken copyright files like: Copyright: GPL or copyright files that list the license with no mention of the copyright holder when the license requires that the copyright notice be preserved (all BSD- and MIT-licensed works). The benefit is really quite high, IMO. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466665: lintian: menu-command-not-in-package should not warn about the use of su-to-root
Paul Wise [EMAIL PROTECTED] writes: It was a package I recently sponsored, they had included an override for the issue. I've removed the override and uploaded the deb here: http://people.debian.org/~pabs/tmp/lynis_1.0.8-1_all.deb Ah, the problem is that lintian isn't smart enough to deal with quoted strings. I think the right thing to do here is to just bail if people use quoted strings for the commands and assume they know what they're doing, since more complex things may be going on than we can easily analyze. I'll do this for the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467019: off-by-one error in debian-changelog-line-too-long (80 column check)
Robert Millan [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: normal The following check: W: nsis: debian-changelog-line-too-long line 3 N: N: The given line of the latest changelog entry is over 80 columns. Such N: changelog entries may look poor in terminal windows and mail messages N: and be annoying to read. Please wrap changelog entries at 80 columns N: or less where possible. is triggered when lines are exactly 80 char, not necessarily over 80 columns as it says. Parse::DebianChangelog was adding an additional space to the beginning of each line (to convert the format into what one would expect in a .changes file presumably). The test needed to be adjusted for that. 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]
Bug#381485: lintian check for direct init script invocation (was: Bug#438885: Not blocking anymore)
Amaya [EMAIL PROTECTED] writes: Important: lintian: Also check for not using invoke-rc.d in other scripts. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381485 I don't have a tremendous amount of free time to work on Debian right now and what time I do have for lintian I'm putting into merging patches. I'd welcome a patch implementing this feature (ideally with some test cases as well). -- 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: [checks/scripts] checkbashsims update
Adam D. Barratt [EMAIL PROTECTED] writes: Predictably, I then spotted another potential hiccup in the /file test. I've simplified it in svn which made the initial error a little more obvious. Please find attached a (hopefully for the final time) revised patch. Thanks, applying in Subversion now. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468804: lintian: Please detect mismatch between bin/sbin and man1/man8, improperly located Perl modules and arch all when should be arch any
retitle 468804 [checks/files] detect *.pm files in /usr/lib severity 468804 wishlist clone 468804 -1 retitle -1 [checks/files] warn of arch-dependent package all in /usr/share severity -1 wishlist thanks Roberto C. Sánchez [EMAIL PROTECTED] writes: It appears that lintian misses some important problems. In the process of preparing to sponsor a package for someone, I came across some oddities and asked about them in #debian-devel. The discussion revealed more problems than I initially realized. I have copied the exchange below, but the summary is: - files in /usr/bin with man pages in man/man8 (the binaries should be either in /usr/sbin or the man pages in man/man1) - the package scatters perl modules about /usr/lib (which really ought to be in /usr/share/perl5) - the package declares itself arch any, but really is arch all. Hi Roberto, In the future, please don't submit bug reports like this that combine multiple problems into a single bug report. Each separate issue should be a separate bug report, since otherwise the maintainer has to clone the bug and retitle it if one bug is fixed and not the other. The first problem that you report is already an open lintian bug (#348864). Please see that bug report for information about why this is harder than it sounds. I think that bug report did arrive at a possible solution for a more limited check, but as yet no one has had time to write the check. The third problem is a consequence of the second problem. lintian has no way of knowing that those files in /usr/lib aren't arch-dependent. If they were all in /usr/share (and with no files in /usr/bin; again, lintian can't know if the Perl scripts contain arch-dependent constants or other code), lintian could warn. I'll clone another bug report for that. The severity of all of these requests is wishlist. lintian doesn't claim to catch everything that's wrong with a package. Bug severities higher than wishlist are for errors in lintian or program malfunctions, not for things that it misses. Thanks for keeping this in mind in the future! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#468876: lintian: please warn when icons are installed in the wrong dirs
Paul Wise [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: wishlist The password-gorilla package that I recently sponsored contains the following files: /usr/share/icons/hicolor/16x16/password-gorilla.png /usr/share/icons/hicolor/32x32/password-gorilla.png /usr/share/icons/hicolor/48x48/password-gorilla.png These are incorrect and will not show up in freedesktop menus because the directory is not listed in the index.theme file. Please check that icons in /usr/share/icons/hicolor are in one of the below directories. [snipped tons of directories] This looks rather unmaintainable from a lintian perspective unless there's some (rarely-changing) standard that specifies those directories. If I'm reading the implications of your message correctly, that list could change arbitrarily with each release of the hicolor theme package. I don't see any clean way that we could maintain this. (Also, this only applies to desktop files that don't give a full path to the icon, no?) Also, when there is a package that contains an index.theme file, it would be good if lintian could validate the locations of images in the package against the Directories parameter in it. Hm, I guess. Parsing desktop files and trying to verify things in them is really hard due to the lack of standardization of desktop files, but this looks reasonably self-contained. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467642: new check for unneeded control scripts
Bernhard R. Link [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.45 Severity: wishlist Attached patch should enable lintian to warn against unneeded control files. It adds a warning against (semantically) empty control files and against some ancient checks. (I don't think package need still check in preinst if the version of dpkg running is newer than from 1999). Frank already added something very similar to this content check and I just enhanced it to warn on scripts containing nothing but the dh-make boilerplate. I'm now also adding these checks for ancient dpkg assertions. 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]
Bug#468876: lintian: please warn when icons are installed in the wrong dirs
Paul Wise [EMAIL PROTECTED] writes: On Sun, 2008-03-02 at 21:18 -0800, Russ Allbery wrote: [snipped tons of directories] This looks rather unmaintainable from a lintian perspective unless there's some (rarely-changing) standard that specifies those directories. If I'm reading the implications of your message correctly, that list could change arbitrarily with each release of the hicolor theme package. I don't see any clean way that we could maintain this. See the Context table at the top if this: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html That only lists some of the subdirectories of your list (it's missing all the stock/* ones) and doesn't use the same names (international instead of intl, applications instead of apps). All of those seem like things that could change on us, no? I wonder if desktop-file-validate would understand all of this. It's on the list to look at whether we can replace the desktop checks in lintian with it. The hicolor standard theme is specified in this: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Interesting, thanks. It would be really good if some of this information could be written up from the perspective of a Debian package maintainer, since right now there's approximately zero information anywhere for how to deal with desktop files if one doesn't personally use Gnome or KDE and isn't familiar with this whole system. I tried to figure this out for gnubg and didn't have a lot of luck. Yah, which is most of them since it gives the icon system theme-ability. On my system, 32 desktop files out of 321 use an absolute icon path. IMO the ones that do are buggy since users cannot override the icons. Ones that use an extension like .png, .svg or .xpm in the Icon field are also buggy because users may want to provide their own versions in a different format. I expect that a lot of the people (like me) who are doing that had no idea what else to do, or that it was even kosher to install files into the hicolor directory. There's a lot of Debian communication missing in this area, I think. lintian can help somewhat, but right now people are working in a void, and adding a few lintian checks probably wouldn't be nearly as useful as writing a comprehensive guide to how a Debian maintainer should tackle these issues. (And then lintian checks can reference the guide.) Isn't this the standard for desktop files? http://standards.freedesktop.org/desktop-entry-spec/latest/ It claims to be, but it's actually the standard for Gnome desktop files. *wry grin*. As I discovered when writing lintian checks against that standard, KDE does something different and uses various fields that aren't listed there. Let alone GnuSTEP, which is even weirder. lintian is currently trying to check sort of a subset of that specification, only desktop files of a particular type, and with additional workarounds for KDE-specific stuff that can't be checked. I'd also like to see a lintian info/warning when a menu file is installed in the package, but a .desktop file is not. The reason for this is that in that case, GNOME users will not have the application in their menu unless they turned the Debian menu on, since it is off by default. The last time someone proposed this, it sparked a huge flamewar on debian-devel. I'm not sure I want to wade back into that. Apparently the GNOME maintainers disabled the Debian menu because they think it's largely worthless, and just blindly reintroducing .desktop files for every .menu file would restore the previous situation. Logically, if every .menu file should correspond to a .desktop file, the GNOME maintainers could just include the Debian menu. Since they don't, that indicates to me that some logic (not yet documented) should be applied by Debian maintainers to decide whether or not to include a desktop file. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452215: lintian: r1238 - in trunk: checks debian testset testset/diffs/debian testset/diffs/debian/patches
[EMAIL PROTECTED] writes: * check/patch-systems: + [HE] Warn if the .diff.gz contains changes while the package uses a patch system. (Closes: #452215) Some people have argued on debian-devel that the correct way to use a patch system is to apply all the patches in the clean target rather than in the build target so that the source package is shipped with all the patches applied. The rationale is that this allows someone preparing an NMU to just ignore the patch system (at the cost of desynchronizing the changes from the patch system for the maintainer). I don't know if we want to allow for that or not. I find the logic dubious, but dpatch supports that mode of operation. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452215: lintian: r1238 - in trunk: checks debian testset testset/diffs/debian testset/diffs/debian/patches
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: I don't know if we want to allow for that or not. I find the logic dubious, but dpatch supports that mode of operation. I have to admit that I consider using a patch system in this way to be a bug. I think we might want to upload with this check and see if there are too many false positives. I'm okay with that. I just wanted to warn in advance, since I expect there will be at least some controversy over it (even though the check has also been requested by others). OTOH, what might be more important would be to introduce checks for other patch systems, but I fear I don't know enough about them to add some checks (especially after seeing how much I didn't know about dpatch...) Adding more tests for quilt is on my list, but behind various other things (such as Policy work). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469106: lintian: False positive for possible-gpl-code-linked-with-openssl
Russ Allbery [EMAIL PROTECTED] writes: Andrew Pollock [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.28 Severity: normal Lintian produces a false possible-gpl-code-linked-with-openssl warning for packages that are not GPL licensed, but contain the magic /usr/share/common-licenses/GPL string in their copyright file because the packaging is GPL licensed. The debian/copyright file in question is attached. Unfortunately, I don't know of a good way to detect this case and still maintain the check absent a machine-parsable copyright format that specifies exactly which files are under which license. (The check was specifically requested by Joerg with his ftp-master hat on.) It's a tough edge case. I slept on this one and can't come up with any good solution. I'm going to add a note to the long description of this tag asking people to use an override for this case (and for the case where the part of the package that links with OpenSSL is independent of the part of the package covered by the GPL). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452215: lintian: r1238 - in trunk: checks debian testset testset/diffs/debian testset/diffs/debian/patches
Bernhard R. Link [EMAIL PROTECTED] writes: But I agree a general warning is nice, though it should be easily circumventable. (Though I guess it always is via renaming the patches dir to something else). Source lintian overrides also work. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469301: lintian: multiarch libraries support
Javier Serrano Polo [EMAIL PROTECTED] writes: Multiarch libraries have their own directories, allowing them to be shared among all architectures. Please add support for this. --- checks/shared-libs.orig 2008-02-04 08:06:01.0 +0100 +++ checks/shared-libs2008-03-04 15:43:35.0 +0100 @@ -31,9 +31,11 @@ qw( lib lib32 lib64 + lib/i486-linux-gnu usr/lib usr/lib32 usr/lib64 + usr/lib/i486-linux-gnu usr/lib/libg++-dbg usr/X11R6/lib/Xaw3d usr/local/lib Are you sure that you want this? This will require that packages that install shared libraries into those directories have shlibs files, call ldconfig, and so forth. Aren't those directories frequently used in arch-independent packages that are installed for cross-building and hence shouldn't provide shlibs and ldconfig calls for the host operating system? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469301: lintian: multiarch libraries support
Javier Serrano Polo [EMAIL PROTECTED] writes:
Multiarch libraries have their own directories, allowing them to be
shared among all architectures. Please add support for this.
Other directories you may want to add besides i486-linux-gnu are:
* arm-linux-gnu
* arm-linux-gnueabi
* hppa-linux-gnu
* m68k-linux-gnu
* mips-linux-gnu
* mipsel-linux-gnu
* powerpc-linux-gnu
* s390-linux-gnu
* sparc-linux-gnu
* x86_64-linux-gnu
--- checks/binaries.orig 2008-02-08 03:56:39.0 +0100
+++ checks/binaries 2008-03-04 15:36:39.0 +0100
@@ -172,7 +172,9 @@
if ($arch eq 'all') {
# package is `Architecture: all' but contains libs!?
- tag arch-independent-package-contains-binary-or-object, $file;
+ tag arch-independent-package-contains-binary-or-object, $file
+ # ignore multiarch directories
+ unless ($file =~ m,^\./(usr/)?lib/i486-linux-gnu/,);
}
# ELF?
I thought I understood what this was for (namely cross-compile support),
but now I realize that I don't. Cross-compiles usually don't use those
paths.
Could you give me more information on what problem you're solving here and
what sort of package would contain files in those directories but be arch:
all?
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469301: lintian: multiarch libraries support
Javier Serrano Polo [EMAIL PROTECTED] writes: Packages are available following http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464796#35 For instance, http://62.43.64.122/debian/pool/ia32/ia32-libtiffxx0c2_3.8.2-7_all.deb Libraries were initially placed in /emul/ia32-linux/usr/lib, sometimes in /usr/lib32. This has evolved to include qemu supported archs (still working on it). shlibs and ldconfig calls are mandatory in biarch case, the trivial same-arch case and they'd support any future combination. I guess they aren't needed for qemu, but that may change in the future. ldconfig should have the chance to decide how to handle those libraries. Oh. Hm. So replacing the /emul stuff. Yeah, okay, I guess this makes sense. I'm not sure that this is the direction Debian is going to go, but I also don't see the harm in making these changes to lintian. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470403: lintian: /var/www
Joerg Jaspert [EMAIL PROTECTED] writes: please issue an E:, or at least W:, on packages having files or links in /var/www. Its a standard reject for me in NEW, with a reason similar to +++---+++ rejected, please remove the var/www link to usr/share. Its a policy/fhs violation to have stuff there *and* it actually doesn't work on many systems. Its wrong to assume var/www is ok. The better way is to setup httpd config snippets for the most common httpds we have that enable the /something to go somewhere sane. See about all the other packages that have such stuff how to do it, please +++---+++ but you might want some better english for it :) Wow, there's a fascinating selection of stuff in the archive that installs files under there. I particularly like dart-server. Will do. 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]
Bug#469924: lintian: suggestion: check for dynamic UIDs or GIDs in file ownership
Håkon Stordahl [EMAIL PROTECTED] writes: Some time ago I attempted a search for packages in the archive with files of suspicious ownership, but not many packages turned out to have such files. Admittedly, fakeroot, dh_fixperms or similar commands seem to catch almost all potential problems. In unstable I could only find strace (see bug #459255). Also, a few other packages from etch or sarge have files with dynamically allocated UIDs and GIDs, but these seem to have been removed or fixed in unstable.[1] I'm actually surprised that we don't see more of this. It is indeed a logical thing to check. Unfortunately, tar doesn't seem to support printing of both the owner ID, which will be required by the new check, and the owner name when it is used to list the files in a package. So when generating the index file for the binary package in the script unpack/unpack-binpkg-l1, the list of files must be extracted from the package, using dpkg-deb and tar, twice. Once where tar is invoked with the --numeric-owner option, and once without it. Ugh. But yeah, nothing for it, and I think the check is useful enough to tolerate this. The actual check is included in the files script, and it simply checks that the owner UID and GID are global IDs, that is from the ranges 0-99, 64000-64999 or 65534. The check could possibly be narrowed futher, for example to check that an ID from the range 0-99 actually has been allocated. I've also added a simple test case for the check. Finally, note there's the theoretic possibility that files in a package might have owner IDs which doesn't properly correspond to the owner names. For example, a file which is stored in the package with owner names someuser:someuser could have owner IDs 0:0. The check won't catch this case, but dpkg will install the files as someuser:someuser (that is, if that user exists on the system). I suppose the check also could be adapted to handle this, but I'm not sure if that's worth the effort. The way to handle this would be to add to Lintian the current reserved users and groups from the base-passwd package and verify that all users match the corresponding UIDs, groups match their corresponding GIDs, and verify that any UID or GID or owner or group is one of the reserved ones. This would probably be a good idea, but I don't have time to implement it at the moment. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Bug#469924: lintian: suggestion: check for dynamic UIDs or GIDs in file ownership
Håkon Stordahl [EMAIL PROTECTED] writes: Hello. I just discovered a slight flaw in an if test in the patch I submitted. The test is just for internal consistency, so it's almost not worth to mention, but here's a simple patch against SVN trunk: Index: checks/files === --- checks/files(revision 1264) +++ checks/files(working copy) @@ -884,7 +884,7 @@ } close(IN); -fail(mismatching contents of index files) if NUMERIC; +fail(mismatching contents of index files) if defined NUMERIC; close(NUMERIC); #check for sect: games but nothing in /usr/games. Check for any binary to (A superfluous 0 at end of file won't trigger the original test.) Sorry for this inconvenience. Oh, no problem, and good catch. I'll fix that now. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: DRAFT: Bits from the Lintian maintainers
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: FWIW, two years ago (?) Jeroen, djpig and I had a discussion about this. The basic idea back then was the same as you describe now: Move away from E, W and I and use two letters to indicate the two different measurements are represented: (i) How certain lintian is: Some checks are heuristics, in other cases lintian is absolutely sure. (ii) How bad a problem is. A spelling mistake (kde instead of KDE) is a bug - on the other hand, broken shlibs handling might be harder to detect, but leads to actual problems. I don't have notes from that meeting (and I think there were never any notes published), so the rest of That's pretty much the same, yup. I think we should probably provide a mapping to E/W/I for backwards compatibility but provide a way of getting more information. I think there's a third metric in addition to the two that you list, namely where does this rule come from, so that people can selectively enable or disable classes of rule origins, although that's probably less common. * Better information retrieval, and caching, of lab information during checks. Right now, all of Lintian's check scripts repeatedly open and reopen files in the laboratory and reparse data in each check script. Instead, that data could be loaded on demand and then cached in case another check script needed it. ACK. Let's get rid of the lab idea, it doesn't help to make lintian easier. While we are at it, we could also finally document what data is collected by lintian in what format. I sometimes need to create a static lab, check a package and look at the unpack results to find out what is already collected. I'm not sure about eliminating the lab entirely, since it's useful as a resource for other sorts of checks and greps, but I think the first step regardless is to provide an abstraction layer for reading data from the lab that caches. Then, if we so choose, we could replace the data source behind that abstraction with some other system without having to change any code. I should try to prototype something and implement a simple data method so that everyone has an example to look at. Another idea discussed in that meeting two years ago was to extend lintian by adding a second tool using pbuilder/piuparts for some checks that require data from other packages. This would of course require net access (or at least access to a Debian mirror), but would finally allow to fix the twenty-something wontfix bugs that require access to other packages. I'm not quite sure how that would fit into the other stuff that lintian does, but definitely something to keep in mind. Anyway, the mail looks fine, please go ahead and post it to dda. I'm just waiting for the complete archive run to finish so that the uploaders information is there, and then I'll do that. Thanks for the review! -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470912: lintian: Please activate no-upstream-changelog
gregor herrmann [EMAIL PROTECTED] writes:
About the only thing why I still run linda after lintian is the
warning about a missing upstream changelog which is quite helpful in
various situations (new changelog, missed in previous build, ...).
I wanted to suggest to add this functionality to lintian, just to
find out that it's already in checks/changelog-file{,.desc} but it's
commented out in the test:
# This tag is disabled for now since a lot of packages fail this
# aspect of policy and I want to clarify policy WRT multi-binary
# packages first.
#tag no-upstream-changelog, ;
My suggestion would be to enable the check but set the Type to info
in changelog-file.desc until the open question is resolved. That way
it could still help interested maintainers without implying a policy
violation.
I don't want to enable it as-is, since it's normal to not include the
upstream changelog in every separate binary package (and I think that's
legitimate; it can be a significant waste of space for packages that are
broken out into a lot of separate library packages, for instance, and have
large changelogs).
It may make sense to enable at the info level when only one binary package
is built from a given source package, but lintian has no way of knowing
that's the case while doing binary package checks.
I don't see a good way to enable this tag that wouldn't produce tons and
tons of false positives, more than I'd be comfortable with even at the
info level. All the good ideas that I can come up with (such as warning
if upstream contains a non-empty NEWS or ChangeLog or CHANGES file that
isn't being installed) require knowledge of the source package and the
binary package at the same time, which structurally lintian doesn't have.
I may be missing some neat way of handling it, though
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470913: lintian: False positive: Manual pages should be compressed with gzip -9
Hideki Yamane (Debian-JP) [EMAIL PROTECTED] writes: I've got warning from lintian, as follows. $ lintian -i ../ccstools_1.5.3-20080131-2_i386.changes E: tomoyo-ccstools: manpage-not-compressed-with-gzip usr/share/man/man8/ccs-auditd.8.gz N: N: Manual pages should be compressed with gzip -9. N: N: Refer to Policy Manual, section 12.1 for details. N: However, it seems that compressed with gzip -9 (max compression). $ file man8/ccs-auditd.8.gz man8/ccs-auditd.8.gz: gzip compressed data, from Unix, last modified: Fri Jan 25 11:32:55 2008, max compression The current version of this package doesn't give this warning, so something must have changed. I gather you either just uploaded this or haven't yet? I don't see it in the archive yet. The warning is based on file output and wouldn't have been issued for the file output you show above, so something weird is going on. -- 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: lintian: r1264 - in trunk: debian lib
Adam D. Barratt [EMAIL PROTECTED] writes:
On Thu, 2008-03-13 at 00:01 +0100, [EMAIL PROTECTED] wrote:
[...]
Log:
* lib/Spelling.pm:
+ [RA] Avoid Perl warnings when called with an uninitialized value.
[...]
Modified: trunk/lib/Spelling.pm
===
--- trunk/lib/Spelling.pm2008-03-12 17:52:44 UTC (rev 1263)
+++ trunk/lib/Spelling.pm2008-03-12 23:01:25 UTC (rev 1264)
@@ -398,6 +398,7 @@
# not defined, it will be omitted.
sub spelling_check {
my ($tag, $text, $filename) = @_;
+next unless $text;
This change appears to generate a new set of warnings however; it should
be s/next/return/:
Exiting subroutine via next at /home/adam/lintian/lib/Spelling.pm line 401.
Exiting subroutine via next at /home/adam/lintian/lib/Spelling.pm line 401.
Exiting eval via next at /home/adam/lintian/lib/Spelling.pm line 401.
Exiting subroutine via next at /home/adam/lintian/lib/Spelling.pm line 401.
(Spotted via having forgotten to unset LINTIANROOT after looking at
#469222 a couple of weeks ago :-)
Good catch. 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]
Bug#470913: lintian: False positive: Manual pages should be compressed with gzip -9
Hideki Yamane [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] wrote: The current version of this package doesn't give this warning, so something must have changed. I gather you either just uploaded this or haven't yet? I don't see it in the archive yet. Just you get source with apt-get source and debuild it, you'll see same warning. The version of this package is ccstools_1.5.3-20080131-1, it's uploaded at 2008-02-06. I'm afraid I don't. After getting the source and building it, I get the same lintian output as I get with the binary package currently in the archive, namely: windlord:~/tmp lintian -I *.changes W: tomoyo-ccstools: maintainer-script-empty preinst W: tomoyo-ccstools: maintainer-script-empty prerm windlord:~/tmp lintian -V Lintian v1.23.46 -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470913: lintian: False positive: Manual pages should be compressed with gzip -9
Hideki Yamane [EMAIL PROTECTED] writes: [EMAIL PROTECTED]:/tmp$ ls *.changes ccstools_1.5.3-20080131-1_i386.changes [EMAIL PROTECTED]:/tmp$ lintian -I *.changes E: tomoyo-ccstools: manpage-not-compressed-with-gzip usr/share/man/man8/ccs-auditd.8.gz E: tomoyo-ccstools: manpage-not-compressed-with-gzip usr/share/man/man8/ccs-ccstree.8.gz [...] [EMAIL PROTECTED]:/tmp$ lintian -V Lintian v1.23.46 Umm?? why I get such errors...? I have no idea. I can't reproduce this. Hm. Do you by any chance have a locale setting? Lintian is suppose to sanitize the environment of anything that causes output to change or the like, but maybe it's missing something. There's *something* different about your environment than mine, but I'm not sure what it is. I built the package in a sid chroot, so it's not that. I'm running the latest version of lintian but on testing, which is another possible difference; if that's it, I can check by running lintian in a current sid environment this evening from home. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470913: lintian: False positive: Manual pages should be compressed with gzip -9
Russ Allbery [EMAIL PROTECTED] writes: I'm afraid I don't. After getting the source and building it, I get the same lintian output as I get with the binary package currently in the archive, namely: windlord:~/tmp lintian -I *.changes W: tomoyo-ccstools: maintainer-script-empty preinst W: tomoyo-ccstools: maintainer-script-empty prerm windlord:~/tmp lintian -V Lintian v1.23.46 I've been able to reproduce this problem now with a current sid chroot. Lintian is correct; the man pages really aren't compressed: wanderer:~/tmp/tomoyo-ccstools/usr/share/man/man8 file *.gz ccs-auditd.8.gz: troff or preprocessor input text ccs-ccstree.8.gz:troff or preprocessor input text ccs-checkpolicy.8.gz:troff or preprocessor input text ccs-domainmatch.8.gz:troff or preprocessor input text ccs-editpolicy.8.gz: troff or preprocessor input text ccs-editpolicy_offline.8.gz: troff or preprocessor input text ccs-findtemp.8.gz: troff or preprocessor input text ccs-init.8.gz: troff or preprocessor input text ccs-ld-watch.8.gz: troff or preprocessor input text ccs-loadpolicy.8.gz: troff or preprocessor input text ccs-notifyd.8.gz:troff or preprocessor input text ccs-pathmatch.8.gz: troff or preprocessor input text ccs-patternize.8.gz: troff or preprocessor input text ccs-queryd.8.gz: troff or preprocessor input text ccs-savepolicy.8.gz: troff or preprocessor input text ccs-setlevel.8.gz: troff or preprocessor input text ccs-setprofile.8.gz: troff or preprocessor input text ccs-sortpolicy.8.gz: troff or preprocessor input text init_policy.sh.8.gz: troff or preprocessor input text tomoyo-init.8.gz:troff or preprocessor input text tomoyo_init_policy.sh.8.gz: troff or preprocessor input text wanderer:~/tmp/tomoyo-ccstools/usr/share/man/man8 head ccs-auditd.8.gz .\ DO NOT MODIFY THIS FILE! It was generated by help2man 1.35. .TH CCS-AUDITD 8 January 2008 ccs-auditd 1.5.3 System Administration Utilities .SH NAME ccs-auditd \- TOMOYO Linux's auditing daemon .SH SYNOPSIS .B ccs-auditd \fIlocation_to_save_grant_log location_to_save_reject_log\fR .SH DESCRIPTION This program reads access request logs from kernel and writes to specified location. .PP It looks an interaction between dh_installman and man --recode is at fault. Upstream installs the man pages already compressed, but then dh_installman does: man --recode UTF-8 ./ccs\-notifyd\.8\.gz ccs\-notifyd\.8\.gz\.new chmod 644 ccs-notifyd.8.gz.new mv -f ccs-notifyd.8.gz.new ccs-notifyd.8.gz for each man page. man can read the compressed man page just fine, but writes out an uncompressed man page, and they're not then recompressed because they still have *.gz extensions. I'll reassign this bug to debhelper. -- 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: GPLv3 x lintian
Luis Furquim [EMAIL PROTECTED] writes: I installed a debian-40r3 in a kvm machine. Now I am customizing the copyright file at the $PACKAGEDIR/debian/ directory. As dh_make generates this file refering to the GPL-2 I have changed it to refer to the GPL-3 and then I took a look at the /usr/share/common-licenses directory and found no GPL-3 document. I found a GPL and a GPL-2 documents, but the GPL and GPL-2 documents are exactly equal as checked with diff. So, where's the GPL-3 document? It will be there only if I install a debian package whose license is GPL-3? I installed only a basic system without any graphic environment. The current stable release of Debian does not include the GPLv3 in common-licenses. It will be included in base-files in that directory in the next stable release of Debian (lenny). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471263: [patch-systems]: please no patch-system-but-direct-changes-in-diff for generated files
Daniel Leidert [EMAIL PROTECTED] writes:
Package: lintian
Version: 1.23.46
Severity: wishlist
Please consider docbook-defguide and docbook-xml/docbook-simple as
examples. In these packages I created a build-system (docbook-defguide)
or catalogs (docbook-xml, docbook-simple). Because I use a patch system
to change upstream sources, lintian complains about the fact, that I do
not create these files by patch.
It simply doesn't make sense to create these files by patch.
Why not?
lintian should only warn, if changes are really changes to an existing
file, but not if change means, that a file has been created.
I can see why you did it the way that you did, but I don't see any clear
advantages over doing it that way versus creating the build files in a
dpatch. It seems like about the same thing to me. Not warning about
newly created files would miss some of the things that this check is
designed to look for (basically, editing the package without being aware
that there's an existing patch system). If a patch created a file and
that file was also shipped in the diff, you end up putting the patch
system in an inconsistent state.
Part of the problem is that people use patch systems in a wide variety of
sometimes odd ways. To some extent, lintian is intentionally being
conservative right now about what uses it's willing to be quiet about,
although I don't know if we'll be able to stick with that in the long run.
Would you agree to this? Is it possible to exclude created files from
this warning? I would further vote for excluding
changes.{sub,guess,rpath} and maybe even Makefiles and/or configure
scripts from this test. However, this is hust an optional suggestion.
I personally think such changes should be made by running the relevant
Autotools at build time, but I realize this is an ongoing debate and
that's far from the consensus at the moment. I think we're still trying
to feel out what Lintian's role should be here. I'd welcome any feedback
from other people reading the mailing list.
--
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: lintian.debian.org no longer updated?
Petter Reinholdtsen [EMAIL PROTECTED] writes: The URL:http://lintian.debian.org/reports/tags.html page currently show this: init.d-script-missing-lsb-section (172 packages, 200 tags, plus 0 overrides) It has shown the same number since 2008-03-13, while I know for a fact that yesterday, only 156 packages had the BTS issue open regarding the missing LSB section. The number is now down to 151. This make me believe the lintian reports are no longer updated. Can you check if the lintian web pages are broken? The problem is revealed on the front page, although is somewhat subtle: Last updated: Mon, 17 Mar 2008 21:11:15 + Archive timestamp: Fri Mar 14 09:00:01 UTC 2008 The ftp.debian.org mirror on gluck is not updating properly, and therefore lintian is still working from old packages. -- 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: lintian.debian.org no longer updated?
Russ Allbery [EMAIL PROTECTED] writes: Petter Reinholdtsen [EMAIL PROTECTED] writes: The URL:http://lintian.debian.org/reports/tags.html page currently show this: init.d-script-missing-lsb-section (172 packages, 200 tags, plus 0 overrides) It has shown the same number since 2008-03-13, while I know for a fact that yesterday, only 156 packages had the BTS issue open regarding the missing LSB section. The number is now down to 151. This make me believe the lintian reports are no longer updated. Can you check if the lintian web pages are broken? The problem is revealed on the front page, although is somewhat subtle: Last updated:Mon, 17 Mar 2008 21:11:15 + Archive timestamp:Fri Mar 14 09:00:01 UTC 2008 The ftp.debian.org mirror on gluck is not updating properly, and therefore lintian is still working from old packages. Looks like it updated today, so this should now be better, although it may have missed some new packages that came in over the last few days. (The package lists were updating when the actual packages were not.) -- 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: lintian.debian.org no longer updated?
Petter Reinholdtsen [EMAIL PROTECTED] writes: [Russ Allbery] Looks like it updated today, so this should now be better, although it may have missed some new packages that came in over the last few days. (The package lists were updating when the actual packages were not.) Great. Yes, it seem to still list a few of the packages that was fixed the last few days. How can I get them updated? The packages ntop, ipsec-tools, guarddog, dmraid, vsftpd, console-cyrillic, spampd, tpconfig, pptpd, libpam-devperm, nstx and mbmon was recently fixed. They'll be picked up if another version of the packages are uploaded. Otherwise, I'd have to run a full archive scan, which will take a couple of days. (In theory, one could update the reporting harness to selectively inspect particular packages, but the code isn't there right now to do that.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471751: False positive: unknown-section base
Thijs Kinkhorst [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.46 Hi, Lintian produces a warning unknown-section base, but the description of that warning is: |The `Section:' field in this package's control file is not one of |the sections in use on the ftp archive. Valid sections are |currently admin, base, comm, devel, doc, editors, electronics, |embedded, games, gnome, graphics, hamradio, interpreters, kde, |libdevel, libs, mail, math, misc, net, news, oldlibs, otherosfs, |perl, python, science, shells, sound, tex, text, utils, web, and |x11. As you can see, base is clearly there, and so is it in policy 2.4. The list of affected packages is here: http://lintian.debian.org/reports/tags/unknown-section.html lintian is slightly ahead of Policy, but base is gone; ftpmaster has already moved all packages out of base and it will be removed from the next Policy release. Please change the section. Thanks for catching the incorrect long description of the tag. I'll fix that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471838: Extend testset for description checks
Tobias Toedter [EMAIL PROTECTED] writes: following your call for help, I decided to write a testset for some tags from private/tags-never-seen. As those tags are mostly from the description checks, I decided to create a new directory called description, I hope this approach is fine with you. Please consider applying the attached patch which adds new tests for 11 tags (the debian/changelog file in the created package is actually correct). Wow, this is great. Thank you! I'll get this into the next release. Moreover, it would be great if you could update the SVN copy of the tags-never-seen file. BTW, how do you generate that file? testset/runtests -v with some munging after the fact. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471537: check for repackaged .orig.tar.gz
Bernhard R. Link [EMAIL PROTECTED] writes: package: lintian severity: wishlist It would be nice if lintian could warn against repackaged .orig.tar.gz, and sources repackaged in non-recommended ways. Attached is some patch that at least seems to be able to detect dh_make's --creatorig usage properly. As both my English language skills and my perl skills could be better, I'm not setting the patch tag. Thank you very much for this. I'll try to get this merged for the next release. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
