Bug#512363: lintian: please detect and warn about swfobject.js

[Paul Wise]

Package: lintian
Version: 2.1.6
Severity: wishlist

swfobject.js is some JavaScript for using flash on the web. It is
currently duplicated in 3 packages in Debian (and one HTML version??):

http://packages.debian.org/search?suite=sid&arch=any&mode=filename&searchon=contents&keywords=swfobject.js

I also found it in plumi, which has been ITPed recently. Please detect
and warn about it like you do for mochikit and other often-embedded
JavaScript snippets.

SWFObject upstream is here:

http://code.google.com/p/swfobject/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

[SCM] Debian package checker branch, master, updated. 2.1.6-1-ga248f9a

[Russ Allbery]

The following commit has been merged in the master branch:
commit a248f9a39bf797928fcc4a769ec9403446709322
Author: Russ Allbery 
Date:   Mon Jan 19 20:45:44 2009 -0800

Add swfobject.js to embedded-javascript-library

* checks/files:
  + [RA] Add swfobject.js to embedded-javascript-library.  Thanks, Paul
Wise.  (Closes: #512363)

diff --git a/checks/files b/checks/files
index b5a7341..fca3732 100644
--- a/checks/files
+++ b/checks/files
@@ -625,6 +625,7 @@ foreach my $file (sort keys %{$info->index}) {
[ qr,(?i)scriptaculous\.js(\.gz)?$, => 'libjs-scriptaculous' ],
[ qr,(?i)fckeditor\.js(\.gz)?$, => 'fckeditor' ],
[ qr,(?i)cropper(\.uncompressed)?\.js(\.gz)?$, => 'libjs-cropper' ],
+   [ qr,(?i)swfobject\.js(\.gz)?$, => 'libjs-yui' ],
[ qr,(?i)yahoo(-(dom-event|min))?\.js(\.gz)?$, => 'libjs-yui' ],
[ qr,(?i)jsjac(\.packed)?\.js(\.gz)?$, => 'libjs-jac' ],
[ qr,(?i)jsMath(-fallback-\w+)?\.js(\.gz)?$, => 'jsmath' ],
diff --git a/debian/changelog b/debian/changelog
index e4c549d..f9cae2a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lintian (2.1.7) UNRELEASED; urgency=low
+
+  * checks/files:
++ [RA] Add swfobject.js to embedded-javascript-library.  Thanks, Paul
+  Wise.  (Closes: #512363)
+
+ -- Russ Allbery   Mon, 19 Jan 2009 20:45:31 -0800
+
 lintian (2.1.6) unstable; urgency=low
 
   * Summary of tag changes:

-- 
Debian package checker


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed: setting package to lintian, tagging 512363

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Automatically generated email from bts, devscripts version 2.10.35lenny1
> # via tagpending
> #
> # lintian (2.1.7) UNRELEASED; urgency=low
> #
> #  * checks/files:
> #+ [RA] Add swfobject.js to embedded-javascript-library.  Thanks, Paul
> #  Wise.  (Closes: #512363)
> #
> package lintian
Ignoring bugs not assigned to: lintian

> tags 512363 + pending
Bug#512363: lintian: please detect and warn about swfobject.js
There were no tags set.
Tags added: pending

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512363: setting package to lintian, tagging 512363

[Russ Allbery]

# Automatically generated email from bts, devscripts version 2.10.35lenny1
# via tagpending 
#
# lintian (2.1.7) UNRELEASED; urgency=low
#
#  * checks/files:
#+ [RA] Add swfobject.js to embedded-javascript-library.  Thanks, Paul
#  Wise.  (Closes: #512363)
#

package lintian
tags 512363 + pending




-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Neil Williams]

On Sun, 18 Jan 2009 19:37:29 -0800
Russ Allbery  wrote:

> > Well that check only works on the source package and only uses msgfmt -
> > it could probably be improved with a check on the binaries and the
> > actual templates file(s).
> 
> Could you explain a bit more about what that would catch that the current
> check doesn't catch, other than the (rather unusual) case of only running
> lintian on the .deb file without running it on the source package?

It allows the check to isolate one particular case:

A new question has been added to the templates file and *NONE* of the
translations include that specific question. The check repeats for all
other questions, uniquely matching the translation status of that one
message against each language. It fails only if NONE of the languages
include at least one specific question.

The result is that this check would then warrant a higher certainty and
a higher severity because it will not pick up the cases where the
translators for some languages have replied and some have not. It will
only pick up cases where *NONE* of the translators have replied.

It gives a high certainty for the problem described by Christian:
 
> Of course, a first package with no translation at all is really
> something we don't like as this makes obvious that no call for
> translations was made and very very likely that no review happened
> (because such reviews always include a recommendation to do a call for
> translations).

It also extends that to a package that includes a new debconf question
that is completely untranslated, with the same degree of certainty.

The test would not affect program translations, only debconf ones.

>  All
> po-debconf checks are currently done against the source package, and if we
> can diagnose the problem on the source package, I'd rather do it there
> since fixing the problem really requires action on the whole source
> package rather than separate actions for each binary package.

The source package does not contain the post-processed templates file
that debconf actually reads. It is the file that is created after the
PO files are merged into the DEBIAN/templates file during the final
stages of the package build.

> > In the original report, I only tested against the .deb. The
> > no-complete-debconf-translation check is not high enough severity to
> > show up without -I when checking the source package.
> 
> Yes, we can change the severity, although I'd like to run that past
> debian-i18n first.

Christian - this is a slightly different problem to what you first
thought. It isn't that some translators have answered and some have
not, it is that a new question has been added and nobody at all has
replied. If a sane deadline is set, isn't it unlikely that not one of
the language teams managed to get a translation to the maintainer in
time? It is far more likely that the maintainer didn't ask the
translation teams before uploading the new question.

The tag name might have to change:

new-question-without-translations

> > If the binary check is added, the certainty can be raised and also the
> > severity. With that change, the description could be made more strict:
> 
> I don't see why a binary check would change the certainty.  Maybe I'm
> missing something? 

The source package check can only process the msgfmt output which is
overly brief. msgfmt does not say whether all translations are missing
the *same* string, it just says that all translations are missing *a*
string. Processing the templates file from the binary uniquely
identifies situations where none of the translations include that
question. As soon as any question is changed, all the old translations
become "fuzzy" and podebconf (via gettext) refuses to include those
translations against the modified question.

> It's certainty: possible right now because there may
> be cases where translators were warned but didn't have a chance to do any
> translations (for an obscure package, for instance).  I think that will
> always be the case.

Then maybe an override can quote the message to debian-18n in the
comments, just as other overrides are meant to quote the bug number? 

If other questions in the templates file *are* translated, it seems
highly unlikely to me that none of the previous translators and none of
the other language teams responded to the call for updates - as long as
a sane deadline was set.

> debian-mentors discussion also raises the valid point that a brand new
> package possibly shouldn't go to translators before the first upload.  I'd
> like to get a debian-i18n opinion on that as well.  Should we skip the
> Lintian tag for no complete translation if this is the first packaging?
> (We can detect this by noting that we only have one changelog entry.)

I disagree with that analysis of the discussion on mentors - I think a
brand new package *should* go to translators before the first upload
and gave my reasons in the thread. New packages using debconf should
have their templa

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Christian Perrier]

Quoting Neil Williams (codeh...@debian.org):

> > Yes, we can change the severity, although I'd like to run that past
> > debian-i18n first.
> 
> Christian - this is a slightly different problem to what you first
> thought. It isn't that some translators have answered and some have
> not, it is that a new question has been added and nobody at all has
> replied. If a sane deadline is set, isn't it unlikely that not one of
> the language teams managed to get a translation to the maintainer in
> time? It is far more likely that the maintainer didn't ask the
> translation teams before uploading the new question.

I agree here. If you manage to get through the problem of having to
examine binary packages' templates, then I agree that having a
template that's marked translatable and *no* translation at all makes
it very likely that no call for translations was issued when the
templated was added.

By "fairly likely", I mean "quite certain", indeed

> The tag name might have to change:
> 
> new-question-without-translations

that would certainly help avoiding the case where maintainers entirely
drop existing translations

A properly worded long information will also help.

> > It's certainty: possible right now because there may
> > be cases where translators were warned but didn't have a chance to do any
> > translations (for an obscure package, for instance).  I think that will
> > always be the case.

Not really, here. Given that some language teams try to commit self to
stay 100%, nearly any new debconf template will be catched.

> > debian-mentors discussion also raises the valid point that a brand new
> > package possibly shouldn't go to translators before the first upload.  I'd
> > like to get a debian-i18n opinion on that as well.  Should we skip the
> > Lintian tag for no complete translation if this is the first packaging?
> > (We can detect this by noting that we only have one changelog entry.)
> 
> I disagree with that analysis of the discussion on mentors - I think a
> brand new package *should* go to translators before the first upload
> and gave my reasons in the thread. New packages using debconf should
> have their templates reviewed.

Entirely agreed.

> > > I'd like to see severity important but normal would be OK for starters.
> > 
> > Remember, the rule of thumb here is that severity should match the
> > severity that you'd pick for the bug that you filed about the problem,
> > were you to file a bug.  Important is a rather large leap over the current
> > severities used for translations.
> 
> Debconf is a little different. It is a peculiar problem that if a new
> debconf question is not translated, the user does not get the chance to
> reconsider their answer when the translation finally arrives.
> 
> Normal severity would be fine if important is deemed a step too far.

I think that normal is a good compromise.




signature.asc
Description: Digital signature

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Neil Williams]

On Mon, 19 Jan 2009 18:27:40 +0100
Christian Perrier  wrote:

> Quoting Neil Williams (codeh...@debian.org):
> 
> > > Yes, we can change the severity, although I'd like to run that past
> > > debian-i18n first.
> > 
> > Christian - this is a slightly different problem to what you first
> > thought. It isn't that some translators have answered and some have
> > not, it is that a new question has been added and nobody at all has
> > replied. If a sane deadline is set, isn't it unlikely that not one of
> > the language teams managed to get a translation to the maintainer in
> > time? It is far more likely that the maintainer didn't ask the
> > translation teams before uploading the new question.
> 
> I agree here. If you manage to get through the problem of having to
> examine binary packages' templates, then I agree that having a
> template that's marked translatable and *no* translation at all makes
> it very likely that no call for translations was issued when the
> templated was added.

Something like this should work:

# i18n -- lintian check script  -*- perl -*-

package Lintian::codehelp;
use strict;
use Tags;
use Util;

sub run {

my $pkg = shift;
my $type = shift;

if (-f "control/templates")
{
my $incomplete;
my $stanza;
open (I18N, '<', "control/templates") or
fail ("cannot open lintian templates: $!");
while ()
{
if (/^Description: /)
{
$stanza++;
undef $incomplete;
next;
}
undef ($stanza) if (/^Description-/);
if ((defined ($stanza) and (/^Template:/)))
{
$incomplete++;
last;
}
}
close (I18N);
tag ("ch-package-contains-docs", "templates") if (defined $incomplete);
}
}

1;


control/templates is safe as we're checking the binary here - we don't
want to be checking debian/foo.templates. It's not perfect, it probably
also need to check that this isn't a source package with:

return if ($type eq "source");

and output the $pkg variable instead of the rather bland "templates".

It simply says that once a Description has been found, there must be a
Description- (this too can be improved) before the next empty line and
following Template stanza. That might need improvement to catch the
last question in the file, especially if there is no terminal newline.
I've not used a sensible tagname either.

Under what circumstances are questions untranslated? There should
always be some help text that needs translation.

> By "fairly likely", I mean "quite certain", indeed
> 
> > The tag name might have to change:
> > 
> > new-question-without-translations
> 
> that would certainly help avoiding the case where maintainers entirely
> drop existing translations
> 
> A properly worded long information will also help.

I'm sure we can come up with that. Something based on:

 debconf only ever asks the same question once - to be effective, that
 question should be translated the very first time that question is
 offered to the user. Translating it after the user has answered the
 question in English is pointless - at least as far as that user is
 concerned.
 .
 This package contains a template file containing at least one question
 that has not been translated at all. This means that translators
 were not properly warned about new strings.
 .
 Translators may be notified of changes using podebconf-report-po, for
 example:
 .
  podebconf-report-po --call --withtranslators --deadline="+10 days" \
  --languageteam
Ref: devref 6.5.2.2

I can spend some more time on this, if you'd like a fully tested patch Russ.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpYwNSe5z91E.pgp
Description: PGP signature

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Russ Allbery]

Neil Williams  writes:

> The source package check can only process the msgfmt output which is
> overly brief. msgfmt does not say whether all translations are missing
> the *same* string, it just says that all translations are missing *a*
> string.

Oh!  Yes, thank you.  That was the point that I was missing.  So the
existing check does have false positives that the check you outline would
not for the problem that you're trying to detect.

If I check the generated templates in the binary deb, how do I check that
the string was marked for translation?  We don't want to trigger this tag
on strings that aren't intended to be translated.

>> It's certainty: possible right now because there may be cases where
>> translators were warned but didn't have a chance to do any translations
>> (for an obscure package, for instance).  I think that will always be
>> the case.

> Then maybe an override can quote the message to debian-18n in the
> comments, just as other overrides are meant to quote the bug number? 

> If other questions in the templates file *are* translated, it seems
> highly unlikely to me that none of the previous translators and none of
> the other language teams responded to the call for updates - as long as
> a sane deadline was set.

That's a good point.  If we check that other things are translated but
this question was not, that's a fairly conclusive sign that the
translators are willing to work on the package and just haven't had an
opportunity to do so.

>> debian-mentors discussion also raises the valid point that a brand new
>> package possibly shouldn't go to translators before the first upload.
>> I'd like to get a debian-i18n opinion on that as well.  Should we skip
>> the Lintian tag for no complete translation if this is the first
>> packaging?  (We can detect this by noting that we only have one
>> changelog entry.)

> I disagree with that analysis of the discussion on mentors - I think a
> brand new package *should* go to translators before the first upload
> and gave my reasons in the thread. New packages using debconf should
> have their templates reviewed.

Okay.  I'll defer to the debian-i18n consensus on this, since it's y'all's
resources that are at stake here.

>> Remember, the rule of thumb here is that severity should match the
>> severity that you'd pick for the bug that you filed about the problem,
>> were you to file a bug.  Important is a rather large leap over the
>> current severities used for translations.

> Debconf is a little different. It is a peculiar problem that if a new
> debconf question is not translated, the user does not get the chance to
> reconsider their answer when the translation finally arrives.

> Normal severity would be fine if important is deemed a step too far.

> I still think it is worth enforcing "no untranslated debconf questions"
> in debian-mentors as a point of good practice - even if the lintian tag
> severity is not changed in order to avoid annoying existing DD's.
> Mentors should be about raising the quality of NEW packages and package
> updates (especially QA uploads etc.) and all packages coming through
> mentors should be up to the latest measures of Policy, Standards and
> general behaviour.

Sure.  I believe that when mentoring you should always run lintian with -I
and ask mentees to fix info-level tags as well (unless they're just
wrong).  Info-level tags are intended to be best practices that people who
don't have a solid reason for doing otherwise should follow, which
describes fairly well the typical mentoring situation.

> Maybe lintian could be more aggressive for checks performed during
> sponsoring than when being used by more "experienced" DD's. ;-)

My hope is that the existing distinction between info and warning, and the
upcoming pedantic support, will provide that extra level of aggressiveness
for those who want it.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Neil Williams]

On Mon, 19 Jan 2009 12:20:40 -0800
Russ Allbery  wrote:

> If I check the generated templates in the binary deb, how do I check that
> the string was marked for translation?  We don't want to trigger this tag
> on strings that aren't intended to be translated.

TBH I was expecting that all questions would be translated - at least
the help text (Description), even if not the possible answers.
Otherwise, doesn't it tend to indicate that debconf is being used as a
registry?

The empirical answer, at the moment, would be as described earlier:
Template:
...
Description: 
 

Template:

should fail - with the proviso that the last question in the file also
needs to be allowed to fail, so check for EOF as well.

Template:
...
Description: 
 
Description-
 ...
Template:

would pass.

A quick check finds these files on my system that contain unexpected
content like:
Template: debconf-apt-progress/info
Type: text
Description: ${DESCRIPTION}

Template: debconf-apt-progress/media-change
Type: text
Description: Media change
 ${MESSAGE}

How are those variables utilised? Where and how could these be
translated?

debconf.templates failed
console-data.templates failed
x11-common.templates failed
gdm.templates failed
console-setup.templates failed
tasksel.templates failed
dbconfig-common.templates failed
linux-image-2.6.24-1-amd64.templates failed
linux-image-2.6.25-2-amd64.templates failed
linux-image-2.6.26-1-amd64.templates failed

That's using a script based on the perl script from the other message.
Out of 65 templates on this system, it's a start.

Choices is a little awkward but I cannot see a scenario where Choices
is *translated* but the Description *is not* so basing the check on
Description alone (to avoid a more common case where Choices is not
translatable) is appropriate, AFAICT.

x11 has:
Template: x11-common/xwrapper/actual_allowed_users
Type: string
Description: internal use only
 This template is never shown to the user and does not require
translation.

Others include:
Template: console-data/bootmap-md5sum
Type: string
Default: none
Description: for internal use

Template: gdm/daemon_name
Type: string
Default: /usr/bin/gdm
Description: for internal use only

Template: console-setup/modelcode
Type: string
Description: for internal use

Template: console-setup/layoutcode
Type: string
Description: for internal use

Template: console-setup/variantcode
Type: string
Description: for internal use

Template: console-setup/optionscode
Type: string
Description: for internal use

Template: console-setup/fontsize
Type: string
Description: for internal use

Template: console-setup/codesetcode
Type: string
Description: for internal use

Those all look wrong to me - debconf for internal use only?

Template: tasksel/desktop
Type: multiselect
Choices: gnome, kde, xfce
Default: gnome
Description: The desktop environment to install when the desktop task
is selected This can be preseeded to change the default.

(That tasksel one looks like a true positive - I can't see why that is
not translated.)

Template: dbconfig-common/missing-db-package-error
Type: select
Choices: abort, retry, ignore
Default: abort
Description: Database package required.
 To properly configure the database for ${pkg}, it is necessary
 that you also have ${dbpackage} installed.  Unfortunately, this can
 not be done automatically.
 .
 If in doubt, you should choose "abort", and install ${dbpackage} before
 continuing with the configuration of this package.  If you choose
"retry", you will be allowed to choose different answers (in case you
chose the wrong database type by mistake).  If you choose "ignore",
then installation will continue as normal.
 .
 (Note to translators: don't bother translating this message yet, as the
  text/wording is not stabilized)

Hmm. That's going to be tricky to identify but probably OK for an
override.

linux-image-2.6.24-1-amd64.templates - none of the strings appear to be
translated and to my eye, all should have been - true positive?

Ditto for linux-image-2.6.25-2-amd64.templates and
linux-image-2.6.26-1-amd64.templates

I'm attaching the script so that others can check their templates
files. (Consider it under the GPL-3+, Copyright me 2009. Note that
it does not currently check for EOF correctly.)

So, overall, only one package needs an override from this cursory
glance at one machine, two packages (four template files) look like
correct checks that should have been caught before (probably) and
another 4 that are using debconf "for internal use" which seems to be
against the spirit of debconf, to me anyway. 

Oh and before anyone asks, I'm not saying that the true positive checks
or the "internal use only" templates need to be fixed for Lenny. ;-)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

#!/usr/bin/perl

opendir (LINT, "/var/lib/dpkg/info/");
@files=grep(/templates$/, readdir(LINT));
closedir (LINT);
foreach $file (@files

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Russ Allbery]

Neil Williams  writes:
> Russ Allbery  wrote:

>> If I check the generated templates in the binary deb, how do I check
>> that the string was marked for translation?  We don't want to trigger
>> this tag on strings that aren't intended to be translated.

> TBH I was expecting that all questions would be translated - at least
> the help text (Description), even if not the possible answers.
> Otherwise, doesn't it tend to indicate that debconf is being used as a
> registry?

Private templates are extremely common.  We can't realistically do
anything that would warn about private templates.  It will just annoy a
lot of people.

Whether that's using debconf as a registry or not is debatable, but I just
raised this point on debian-devel and several people commented that they
prefer private templates for things that can be adjusted by preseeding but
aren't worth prompting the user about.  There are also reasons to use
private templates as a way of storing information about how the package
has handled debconf settings.  For example, krb5-config uses a private
template of type boolean:

Template: krb5-config/read_conf
Type: boolean
Default: true
Description: For internal use only
 We want to try and capture user changes when they edit a config file
 manually.  To do this, we look in the config script to read the file.
 However, in the case of preconfigure, the config script is run twice
 before the postinst is run.  Thus, we may read the wrong value before the
 edited value is written out in postinst.  If this is false, we skip
 reading config files until postinst runs.

I think this sort of thing is quite common.

for this sort of check, I want to trust the package maintainer when they
decide what is translatable and what isn't.  We already warn them if we
think they're not marking something as translatable that should be in the
source package checks.

> A quick check finds these files on my system that contain unexpected
> content like:
> Template: debconf-apt-progress/info
> Type: text
> Description: ${DESCRIPTION}
>
> Template: debconf-apt-progress/media-change
> Type: text
> Description: Media change
>  ${MESSAGE}
>
> How are those variables utilised? Where and how could these be
> translated?

debconf is currently exempted from this check because it does complex
things internally that Lintian can't analyze.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Neil Williams]

On Mon, 19 Jan 2009 14:54:26 -0800
Russ Allbery  wrote:

> Neil Williams  writes:
> > Russ Allbery  wrote:
> 
> >> If I check the generated templates in the binary deb, how do I check
> >> that the string was marked for translation?  We don't want to trigger
> >> this tag on strings that aren't intended to be translated.
> 
> > TBH I was expecting that all questions would be translated - at least
> > the help text (Description), even if not the possible answers.
> > Otherwise, doesn't it tend to indicate that debconf is being used as a
> > registry?
> 
> Private templates are extremely common.  We can't realistically do
> anything that would warn about private templates.  It will just annoy a
> lot of people.

OK, I think there is a way of identifying private templates. It could
be as simple as agreeing (after Lenny) that a particular Description is
uniformly used for all private templates. That would help translators
too. Most already seem to use "for internal use". After all, the
description itself is completely arbitrary as far as internal templates
are concerned.

Indeed, simply adding one line to the test script could be enough:
next if ($line =~ /^Description: .*[for ]?internal use/);

Which gives: (excluding debconf.templates as you described)

tasksel.templates failed
dbconfig-common.templates failed
linux-image-2.6.24-1-amd64.templates failed
linux-image-2.6.25-2-amd64.templates failed
linux-image-2.6.26-1-amd64.templates failed

dbconfig probably needs an override and the others look like correct checks.

Until there is consensus on the syntax for private templates, the
lintian test could stay at lower severity.

> Description: For internal use only

That would match too - so it would be ignored for the test.

> I think this sort of thing is quite common.

As long as a particular identifier can be used for all (and the lintian
test can provide information on that identifier in the guide text),
that shouldn't be a problem.
 
-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgprvn2hu4gOp.pgp
Description: PGP signature

Processed: tagging 492626

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Automatically generated email from bts, devscripts version 2.10.35lenny1
> tags 492626 - moreinfo
Bug#492626: [checks/po-debconf] don't require po-debconf if all debconf 
questions are internal
Tags were: moreinfo
Tags removed: moreinfo

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings

[Russ Allbery]

Neil Williams  writes:

> OK, I think there is a way of identifying private templates. It could be
> as simple as agreeing (after Lenny) that a particular Description is
> uniformly used for all private templates. That would help translators
> too.

Well, it shouldn't help translators because those templates should not be
marked as translatable anyway.  It would just be an additional requirement
that we're adding for people writing debconf templates so that they don't
get Lintian warnings.

> Most already seem to use "for internal use". After all, the description
> itself is completely arbitrary as far as internal templates are
> concerned.

Some examples of untranslated templates that don't use that string are:

cdebootstrap (a udeb special case)
cpufrequtils
etcinsvk
kickseed (maybe an actual bug)
lowmem

Many of them use variations on it.  Those are just the ones that I can
find because they don't use po-debconf at all and hence Lintian currently
warns (but won't after I fix #492626).

Looking in more depth, while Lintian currently uses the internal use part
to suppress checks for grammar and the like, there is currently no check
in Lintian for a template that isn't marked as translatable but should be.
I think we therefore have no idea how many false positives we're likely to
uncover.  We could introduce this as experimental first and see what
lintian.d.o digs up, though.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org