tag 560414 patch
thanks
Attached a patch that implements this. It changes the name of the local
variable (template) 'type' which currently shadows the higher level
(package) 'type' variable.
Cheers,
FJP
--- checks/debconf.orig 2010-01-31 10:02:32.0 +0100
+++ checks/debconf 2010-02-09
Package: lintian
Severity: wishlist
X-Debbugs-CC: debc...@packages.debian.org
Some packages use the command 'db_title' in maintainer scripts to set the
title for debconf dialogs to a fixed string. Disadvantage is that this
does not allow the string to be translated.
Because of that the command
Package: lintian
Version: 2.2.18
Severity: wishlist
X-Debbugs-CC: debian-b...@lists.debian.org
Concerns check: too-long-short-description-in-templates
As can be seen on [1] there are a lot of warnings of this type, especially
for udebs. For udebs all cases are templates of type text that
Russ Allbery wrote:
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?
The braces are required.
I assume that something like the following pseudocode would work:
On Sunday 23 December 2007, Russ Allbery wrote:
The new scheme is:
http://lintian.debian.org/reports/maintainer/email.html
The links from those pages to error descriptions are broken:
http://lintian.debian.org/reports/maintainer/Tnewer-debconf-templates.html
404 Not Found
There's no
Package: lintian
Version: 1.23.25
Severity: minor
Tags: d-i
If I build and check for example choose-mirror for Debian-Installer, I'll
get a number of warnings for mismatch-translated-choices even though the
number of choices of the translation _does_ match the original.
Reason is probably that
Package: lintian
Version: 1.23.16
The Indices field is used to sort entries in a select or multiselect
question.
It is supported in cdebconf; I'm not totally sure about debconf.
However in this case I feel it would be better to not warn about it even
if it is not be supported by debconf as it
Package: lintian
Version: 1.23.15
#321750 introduced a new check shlib-without-PT_GNU_STACK-section in
lintian 1.23.13. Is it possible that this check is not valid for all
architectures?
The check fired after I compiled freetype for an NMU on HPPA. It does not
fire if I perform the same
Package: lintian
Version: 1.23.15
Tags: d-i
http://lintian.debian.org/reports/Tunused-shlib-entry-in-control-file.html
currently shows several packages with the following warning:
unused-shlib-entry-in-control-file udeb:
For an upcoming upload of expat, the following warning can occur as
9 matches
Mail list logo
