Bug#705197: Language-Team field in po files should not contain debian-i18n@l.d.o
(please keep debian-i18n CC'ed to answers) Quoting Andrei POPESCU (andreimpope...@gmail.com): > Package: lintian > Severity: wishlist > X-Debbugs-CC: debian-i...@lists.debian.org > > On Ma, 09 apr 13, 08:25:37, Christian PERRIER wrote: > > > > To translators : please don't set debian-i...@lists.debian.org as > > Language-Team mailing list address in PO files. Better use the list > > dedicated to your language. > > > > Otherwise, calls for translation updates get sent to debian-i18n which > > is not very useful (Russ, no harm, of course, you can't check each and > > every PO file for this). > > Maybe lintian could? Good idea. Anyone coming up with a patch (I could risk doing that but my perl-fu is somehow limited)? I bet Russ will include this in lintian if we provide a patch. We however need to also provide an explanation that lintian will give when people meet this condition. In short, we need to explain maintainers what should be done: - either contact the person listed in Last-Translator and suggest him|her to provide a "better" Language-Team field - replace Language-Team with the releavant Debian language team: this should be done only for debian/po/*.po *not* for upstream translations...and this is anyway not the best suggestion for maintainers to fiddle with this - empty the field (probably the best solution, imho) signature.asc Description: Digital signature
Bug#677870: lintian: Shouldn't warn about unknown template type "entropy" when a package depends on cdebconf
Package: lintian Version: 2.5.7 Severity: normal cdebconf has a template type that debconf doesn't have, namely "entropy". As a consequence, a package that uses such template but it depending on cdebconf shouldn't trigger the following warning: E: partman-crypto udeb: unknown-template-type entropy (frankly speaking, I guess only partman-crypto is using that template, but still..:-)) -- System Information: Debian Release: wheezy/sid Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.22-6 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.11-1 ii gettext0.18.1.1-8 ii hardening-includes 2.1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libc-bin 2.13-32 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.3 ii libemail-valid-perl0.190-1 ii libipc-run-perl0.91-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii locales2.13-32 ii locales-all [locales] 2.13-32 ii man-db 2.6.1-2 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-10 ii unzip 6.0-6 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch ii dpkg-dev 1.16.3 ii libhtml-parser-perl3.69-2 ii libtext-template-perl 1.45-2 ii man-db 2.6.1-2 ii xz-utils 5.1.1alpha+20110809-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120617115637.27274.53714.report...@mykerinos.kheops.frmug.org
Bug#677649: lintian: Checks disabled for "XC-Package-Type: udeb" should be disabled for "Package-Type: udeb" too
Package: lintian Version: 2.5.7 Severity: normal I started using "Package-Type: udeb" in several D-I source packages. however, once this is done, several tests that are disabled for "XC-Package-Type: udeb" then trigger warnings or errors. For instance, "no-standards-version-field" but also several other. Reporting this after a heavy mass upload for D-I, so I can't investigate more but I think you get the point. Hopefully, I can come back with more details if needed. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.22-6 ii bzip2 1.0.6-1 ii diffstat 1.55-2 ii file 5.11-1 ii gettext0.18.1.1-8 ii hardening-includes 2.1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libc-bin 2.13-32 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.3 ii libemail-valid-perl0.190-1 ii libipc-run-perl0.91-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii locales2.13-32 ii locales-all [locales] 2.13-32 ii man-db 2.6.1-2 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-10 ii unzip 6.0-6 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch ii dpkg-dev 1.16.3 ii libhtml-parser-perl3.69-2 ii libtext-template-perl 1.45-2 ii man-db 2.6.1-2 ii xz-utils 5.1.1alpha+20110809-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120615180428.30591.15494.report...@mykerinos.kheops.frmug.org
Bug#622149: [Pkg-fonts-devel] Bug#622149: lintian: false positive: font-in-non-font-package in fonts-* package
Quoting أحمد المحمودي (aelmahmo...@sabily.org): > Package: lintian > Version: 2.5.0~rc2 > Severity: normal > Tags: patch > > The Debian Fonts Task Force have agreed to name font packages using the > following naming scheme: fonts-- > > Yet, lintian gives a font-in-non-font-package when it finds a font in > packages with that naming scheme. > > Attached is a patch to fix this issue. IIRC, there already has been such request to lintian maintainers. However, as this new policy is not yet as strongly published as it should, they logically deferred the change. So, well, I would have no problem if this bug fix is delayed until we really publish the font packages policy (starting from what Rogério wrote and published in the mailing list a few weeks ago). signature.asc Description: Digital signature
Re: [Pkg-fonts-devel] Lintian error with new font package name convention
Quoting Daniel Kahn Gillmor (d...@fifthhorseman.net): > I don't think this needs to go any formal DEP-style route if there is no > controversy on the pkg-fonts-devel team. Let's just write up the > consensus on the wiki and move forward. Added to my TODO pilebut, really, I would welcome another pkg-fonts team member to propose such draft policy.:) signature.asc Description: Digital signature
Re: [Pkg-fonts-devel] Lintian error with new font package name convention
Quoting Daniel Kahn Gillmor (d...@fifthhorseman.net): > On 02/09/2011 12:40 PM, Vasudev Kamath wrote: > > Hi, > > I'm packaging the following font package > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571723 > > > > As per my previous mail to the list I'm using new font name convention > > (fonts--name). But I'm getting lintian error on the new font > > package naming convention. Lintian is suggesting me to use ttf-* otf-* > > format. How I can I suppress/override the lintian warnings? > > > > Here is part of lintian warning > > > > I: fonts-johnsmith-induni: font-in-non-font-package > > usr/share/fonts/opentype/fonts-johnsmith-induni/IndUni-C/IndUni-C-Bold.otf > > > i'd say the right thing to do is to fix lintian to the new package > naming convention. > > Could you file a bug report against lintian, pointing to the new fonts > package naming policy? I don't know where that is. Ahem. Nowhere? :-) This has been discussed in the pkg-fonts team, but no policy has been written as of now (or no update of existing policy, if there's one, which I'm unsure about). signature.asc Description: Digital signature
Re: [Bug 233674] kipi-plugins: unknown-locale-code hne i8n
> > So, maybe lintian could check that, if foo_BAR.po file exists in a > > package, there is at least one foo_* file in /usr/share/i18n/locales > > Am I missing something or wouldn't adding the 639-3 codes to the list > of known and valid codes be enough? Actually, if a locale doesn't exist in the glibc, translations for that locale won't be used, so checking against /usr/share/i18n/SUPPORTED seems to be the right thing to do. I'm not sure, though, that it is really a good idea to check PO files against supported locales, for "upstream" translations (ie non-debconf ones) with lintian. The only case where it's relevant to lintian, imho, is the case where the package is native (so "upstream" is Debian). signature.asc Description: Digital signature
Re: [Bug 233674] kipi-plugins: unknown-locale-code hne i8n
Jumping in that thread (you would have guessed I would, right? :-)) > Mark Purcell wrote: > > > On Friday 09 April 2010 08:30:14 Albert Astals Cid wrote: > >> hm? eh? what? why would we remove a perfectly valid translation to a > >> language spoken by 11 million people? > > > > Albert, > > > > I don't think the issue is the removal of the translations, rather the > > fact that the locale-code hne isn't defined in ISO 639-1 & ISO 639-2. > > > > My reading of Chhattisgarhi_language[1] shows that the ISO 639-3 code is > > "hne", whilst the ISO 639-2 code for this family is "inc". > > > > I am raising this as an inconsistency. If we are accepting ISO 639-3 > > locales then that is fine too and we will fix lintian. We are: bubu...@mykerinos:~/src/debian/iso-codes/git/iso_639_3> ls -l /usr/share/i18n/locales/hne_IN -rw-r--r-- 1 root root 5393 7 févr. 18:26 /usr/share/i18n/locales/hne_IN We also have several other locales with ISO-639-3 codes: /usr/share/i18n/locales/ast_ES: Asturian (Spain) /usr/share/i18n/locales/byn_ER: Bilin (Eritrea) /usr/share/i18n/locales/crh_UA: Crimean Turkish (Ukraine) /usr/share/i18n/locales/csb_PL: Kashubian (Poland) /usr/share/i18n/locales/fil_PH: Filipino (Philippines) /usr/share/i18n/locales/fur_IT: Friulian( Italy) /usr/share/i18n/locales/gez_ER: Geez (Eritrea) /usr/share/i18n/locales/gez...@abegede /usr/share/i18n/locales/gez_ET: Geez (Ethiopia) /usr/share/i18n/locales/gez...@abegede /usr/share/i18n/locales/hne_IN: Chhattisgarhi (India) /usr/share/i18n/locales/hsb_DE: Upper Sorbian /usr/share/i18n/locales/mai_IN: Maithili (India) /usr/share/i18n/locales/nan...@latin: Min Nan Chinese (Taiwan) /usr/share/i18n/locales/nds_DE: Lower Saxon (Germany) /usr/share/i18n/locales/nds_NL: Lower Saxon (Netherlands) /usr/share/i18n/locales/nso_ZA: Northern Sotho (South Africa) /usr/share/i18n/locales/pap_AN: Papiamento (Netherlands Antilles) /usr/share/i18n/locales/shs_CA: Shuswap (Canada) /usr/share/i18n/locales/sid_ET: Sidamo (Ethiopia) /usr/share/i18n/locales/tig_ER: Tigre (Eritrea) /usr/share/i18n/locales/wal_ET: Wolayttia (Ethiopia) There are even some locales that correspond to *no* ISO-639-3 code /usr/share/i18n/locales/ber_DZ: Berber (Algeria) /usr/share/i18n/locales/ber_MA: Berber (Morocco) (here I think this is a bug. The code to use should be the code for Tamazight...but indeed the Berber/Tamazight language uses two scripts, the fact that Berber and Tamazight are different or not is debated between Algeria and Morocco and all this is a highly sensitive political issue and that may explain this inconsistency...which is, still, done the wrong way) All of them are here (and come from glibc upstream) because the said languages have no ISO-639-2 code. > > > > Right, but the first faulty package is isoquery. The isoquery program is not > able to display the ISO 639-3 codes: > > TODO for Isoquery > > = > > > > - allow use of ISO 639-3 > > The reason I assume is that there's no (given the nature of the ISO 639-3 > standard) translation table between ISO 639-3 and ISO 639-2 codes. > > So I guess the most we can do is just inject the 639-3 codes and hope for > the best (i.e. hope people is going to use the best and most appropriate ISO > 639-1..3 code.) That's correct about isoquery's capabilities that should be enhanced. Maybe, if possible, check that a locale exists for the said language. We can quite safely assume that, if a locale exists with a given ISO-639-3 code, then it has been carefully though by glibc maintainers (either upstream or Debian/Ubuntu maintainers). Indeed, if a translation file exists for a locale that doesn't exist, there are chances that it isn't used.particularly because users will have more problems in setting this locale in their environment. So, maybe lintian could check that, if foo_BAR.po file exists in a package, there is at least one foo_* file in /usr/share/i18n/locales And, subliminal message to Chhattisgarhi translators: I would very much welcome a work on localization for Debian Installer that would help in adding Yet Another Indic Language to the already quite long list of supported Indic languages in Debian and Ubuntu installers..:-) signature.asc Description: Digital signature
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
(keeping CC as I don't know who's subscribed to what) Quoting Colin Watson (cjwat...@debian.org): > > 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.) > > Because it's never asked; it's preseeding-only. The installer > intentionally doesn't offer this as a choice by default (and let us not > reopen that most endless of discussions here), but it's available for > preseeding for people customising the installer. > > Again, Lintian is not smart enough to second-guess this and shouldn't > try. I basically agree with what Colin was saying up to there.but not to that last affirmation. The lintian check about translatability avoided a lot of non translatable debconf templates (at least this is a guess...but when it was introduced, I saw a bump in new strings for debconf templates, showing that many maintainers realized they were omitting something). So, I'd vote for this check to be kepteven though there are many cases where it will be legitimate to ignore that lintian warning. signature.asc Description: Digital signature
Bug#514095: lintian: Should not report for duplicate files|fonts in binary packages when one of the packages is a udeb
Quoting Adam D. Barratt (a...@adam-barratt.org.uk):
> One part of the patch I wasn't entirely sure about, so haven't applied
> yet, was the change to allow udebs to contain fonts when the package
> name does not start with "otf-" or "ttf-". Christian, is this something
> that's worth enforcing at the udeb level as well, or are udebs
> containing fonts likely to legitimately have other names?
Currently there are none of such packages, TTBOMKand I don't see
any reason for having some in the future.
In short, I think it's safe to assume that udeb containing fonts
should be named {ttf|otf}-
signature.asc
Description: Digital signature
Bug#514095: lintian: Should not report for duplicate files|fonts in binary packages when one of the packages is a udeb
Package: lintian Version: 2.2.0 Severity: minor While compiling ttf-freefont to sponsor its upload, I noticed the following: W: ttf-freefont-udeb udeb: duplicate-font-file usr/share/fonts/truetype/freefont/FreeSansBold.ttf also in ttf-freefont This is of course completely intended. Having a udeb provide the same file than a regular deb package is very common and, indeed, most of the time, the purpose of a udeb package, particularly in font packages..:-) I think that, if feasible, this test should not compare the content of udeb packages with the content of deb packages. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.46-1 produces graph of changes introduc ii dpkg-dev1.14.24 Debian package development tools ii file4.26-2 Determines file type using "magic" ii gettext 0.17-6 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libipc-run-perl 0.82-1 Perl module for running processes ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.2-4 on-line manual pager ii perl [libdigest-sha 5.10.0-19Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch (no description available) ii libtext-template-perl 1.44-1.2 Text::Template perl module ii man-db2.5.2-4on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512210: lintian: [checks/po-debconf] Extend template check for updated strings
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
(I haven't looked #512210 yet) Quoting Russ Allbery (r...@debian.org): > > 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. I'm not entirely enthusiast to increase the severity. Having incomplete PO files is not an error per se. And the maintainer might very well have sent a call for translaiton updates but not received any input from some translators. That happens very often. So, I would not like some maintainers to consider that the translation file is bogus and not include it, while it is just safe to keep it as is. > > > 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? 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. *Yes*. Really, I see no real good way to actually check if translators were warned (as this is done by mail). So, the current warning is the only thing that should be done, imho... > 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.) On first packaging, what we would see is first a review of English messages in debian-l10n-english (yet another thing you can't really detect) before the call for translations is issued to -i18n. 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). > > > 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. Agreed. Even though we consider l10n to be important, I think that overflating severities for it would very likely make maintainers angry for no real benefit. signature.asc Description: Digital signature
Re: [SCM] Debian package checker branch, master, updated.1.24.2-6-g051f191
Quoting Adam D. Barratt ([EMAIL PROTECTED]): > I think the makefile example's slightly different, as the tag doesn't > refer to another document where the topic is discussed in more detail and > where the example could possibly more usefully be included. That's just > MHO though. The only problem I see is that DevRef does not give the podebconf-report-po example...yet. I agree it should but this falls in my "lot of stuff I really should do" pile..:) signature.asc Description: Digital signature
Re: [SCM] Debian package checker branch, master, updated. 1.24.2-6-g051f191
Quoting Jordà Polo ([EMAIL PROTECTED]): > Christian Perrier pointed out that the description should mention 1) > that these are debconf templates translations and 2) the > podebconf-report-po script, preferably including an example: > > podebconf-report-po --call --withtranslators --deadline="+10 days" \ > --languageteam > > I certainly agree with the former. There is no context in lintian > reports, so we really need to mention debconf somewhere, it would be > confusing otherwise (actually, I would even change the name of the tag > to something like "no-complete-debconf-translation"). > > I'm not so sure about the latter though. podebconf-report-po already > appears in the referenced section of the Developer's Reference. And if > needed, wouldn't it be more useful to include that particular example in > devref itself? Well, lintian messages are full of such small examples (I'm for instance thinking about the warning about "should not ignore errors from make" which gives a nice bit of code to put in debian/rules.which I find useful when I have a package affected by this "problem". signature.asc Description: Digital signature
Re: Ideas wrt debconf templates checks
Quoting Esko Arajärvi ([EMAIL PROTECTED]): > 1. Changelog proclaims a bug closed > 2. The bug is marked with tags l10n and patch > 3. There's a po file attached to the bug report > 4. This po file is not in the package's po directory That would give false positives in the case where a maintainer closes l10n bug reports for debconf templates because (s)he just removed all debconf templates for that package. And Adam also gave a valid objection to this. But, yes, I understand that what you described is really annoying..:) signature.asc Description: Digital signature
Ideas wrt debconf templates checks
Hello Lintian maintainers and i18n 'informal team', Before I report this as a wishlist bug, I'd like to have your input on two ideas that popped up in my mind for possible lintian checks wrt debconf templates: 1) Checking if a declared template is still used Sometimes, maintainers rewrite maintainer scripts and remove the use a a given debconf template but do not think about dropping it from debian/*templates. It therefore clutters the debconf database and adds extra useless work to translators. Would a check for such situation be feasible, reasonable, in your opinion ? Does it already exist ? :-) 2) Checking for maintainers who forgot to send a call for translations Many people know this is the best way to make me grumpy..:-) Some people suggested /me to propose a check for incomplete translations: have lintian warn if one of the files in debian/po is not fully translated. While possible, I think this would have the negative effect that maintainers would be tempted to remove it to make their package "lintian clean"...which is not what they should do. However, if *all* files are incomplete, it is very likely that the maintainer indeed changed something in the debconf templates and did not care (or did not take time) to send a call for translations. So, I'm tempted to propose a check for this but would like to get your advice before. -- signature.asc Description: Digital signature
Bug#482795: lintian: should not recommend debian/templates.pot to exist in source
> > > Lintian complains about this, because it means that the file is not > > > present in the source package. IMO this is incorrect: generated files > > > should not be present in the source package. There's still discussion > > > (which I intend to restart) if it is acceptable to leave them in after > > > running the clean target, but AFAIK there's no discussion that it is > > > acceptable to remove them. Of course I could be wrong about that. :-) Hell, no. IT IS NOT ACCEPTABLE. POT files are the material needed by translators to work on. Assuming they'll be able to generate them from cryptic gettext commands, run autostuff magic, and weird incantations to get the very basic file they need is just wrong wrong wrong wrong. Please *don't* remove generated POT files from upstream source. Please don't remove debian/po/templates.pot. Please don't change lintian. This is IMHO a developer's disease to have the will of providing "clean" source, "clean" from generated stuff. This is often a good disease but, in that case, this is a very bad one. Please provide us with the material we need and don't hide it under layers of code. Of course, all i18n infrastructure could maybe be adapted in some way and cope with missing templates.pot files. But, actually, we can't assume that all translators will use the i18n infrastructure to get the material. Just like we can't assume that upstream translatros will egt the material they work on from Rosetta, Pootle or whatever fancy tool used to assist l10n work. We already have stuff and packages in Debian that hide POT files (the debconf package comes to mind)and that's already a PITA. Yes, I know it means that developers have to maintain generated files in their VCS. So what? > > > > Perhaps I'm missing something here, but it looks like both > > translators[1] and the website[2] still expect the templates.pot file to > > be there. Wouldn't it make more sense to update the website and i18n.d.n > > scripts[3] before removing the lintian check? It would make sense to *not* change lintian and packages before that happens. And making that happen with collaboration of i18n people is very very unlikely. Because it is plain wrong to not provide POT files, period.because it breaks existing practice, that works, for just the sake of being "clean". > Anyway, thanks for the comments, my report suggested to ignore the > translators and break their procedures. This was not my intention, of > course. Thanks for the comment. For sure, CC'ing -i18n in the original bug report would have been a good idea: I could have started to shoot much much earlier..:-) signature.asc Description: Digital signature
Bug#481152: lintian: Promote the use of "__Choices" in debconf templates files
Package: lintian Version: 1.23.48 Severity: normal First of all, sorry for no coming up with a patch. This is something I'm not skilled for...as of now;.:-) I think it would be good for lintian to promote the use of "__Choices" over "_Choices" in debconf templates. This feature is present since po-debconf exists so, indeed, no compatibility problems. The feature is well documented in po-debconf(7). I send this bug report evn if I know it might be incomplete to be processed as of now. Anyway, I recommend *not* activating this before lenny is released. Detection: This can be detected by looking for "^_Choices" in debconf templates files. There are no known exceptions where using "_Choices" is to be preferred over "__Choices". Proposed lintian tag: unsplitted-choices-in-templates Additionnal parameter to report: The name of the offending template (just like all other debconf templates checks) Proposed information text: The Choices field of a debconf template is using "_Choices". That makes the choices translatable altogether in a single string, which is likely to trigger errors by translators if they don't use the same number of choices than original text. It is recommended to use "__Choices" instead. Before blindly replacing all occurrences of "_Choices" by "__Choices", you must apply the method described in po-debconf(7) under "SPLITTING CHOICES LIST", to avoid breaking existing translations. If in doubt, please ask for help on the debian-i18n mailing list. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.19 package building tools for Debian ii file4.24-2 Determines file type using "magic" ii gettext 0.17-2 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-1 on-line manual pager ii perl [libdigest-sha 5.10.0-10Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- 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
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..:-) > > > 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. 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. signature.asc Description: Digital signature
Re: Some fixed warnings still showing up on lintian.d.o
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 http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html Not Found The requested URL /reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html was not found on this server. Apache/1.3.33 Server at lintian.debian.org Port 80 I'm afraid somethign is b0rken somewhere:) signature.asc Description: Digital signature
Some fixed warnings still showing up on lintian.d.o
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? -- signature.asc Description: Digital signature
Re: Another raw idea for lintian check: variable substitution in debconf templates
Quoting Russ Allbery ([EMAIL PROTECTED]):
> 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?
Frans answered and his answer is obviously correct.
>
> > 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:
No advice there.
About Frans' suggestion to leave such check up to the future
translation status page: I'm not entirely keen for this. IMHO,
maintainers should have a way to detect translations than can be very
misleading to users.
Of course, the tricky point is suggesting maintainers that they should
*not* try to fix the "error" themselves unless they are 1000% sure
they won't break something. Otherwise, suggestion to mark the string
as "fuzzy" is better. Example of a fuzzy string:
#. Type: select
#. Description
#: ../templates:3002
#, fuzzy
msgid "Type of automatic serial port configuration:"
msgstr ""
"¿Qué tipo de configuración automática del puerto serie quiere utilizar?"
As you see, the key is the line before msgid, marked as a "comment"
and containing "#, fuzzy" (the comma is needed).
signature.asc
Description: Digital signature
Bug#464511: detect a fully vaild .po file as non-valid
Quoting Eddy Petri?or ([EMAIL PROTECTED]):
>>> There is also a niederdeutsche Version of wikipedia [2].
>>
>> debian-i18n folks:
>>
>> Currently, the regex used by lintian to validate po file names is:
>>
>> /^[a-z]{2,2}(_[A-Z]{2,2})?\.po$/
>>
>> so it expects language codes in the form:
>>
>> nn
>> nn_NN
>>
>> It looks like this is an ISO 639-2 language code. Should lintian be
>> allowing for those in po file names as well? In other words, should I
>> also permit:
>>
>> nnn
>
> Yes. There are languages that do not have a 639-2 iso code, but have a
> 693-3 iso code (example Creoles and pidgins, French-based)
My suggestion for PO files:
nn_NNN is OK *as long as there is a valid locale on the system for
it*. So, for instance fr_AU.po ("French as spoken in Australia") is an
invalid PO file.
nn or nnn are OK *as long as there is at least one valid nn_XX or nnn_XXX
locale on the system*
That means that we leave up to the locales package to decide whether
or not a locale (and therefore a PO file) is valid or not.
So, a suggestion (but I dunno if that can be used or not) would be to
check with the content of /usr/share/i18n/SUPPORTED, removing charset
cruft from there with something like:
cat /usr/share/i18n/SUPPORTED | cut -f1 -d\. | cut -f1 -d\@ | awk '{print
$1};'|uniq
(this is bubulle shell style: Perl guru can do better)
That would require lintian to depend on locales which you might not
want, however.
Otherwise, you can at least check PO files to be either "nn", "nnn",
"nn_XX", "nnn_XX". There is no case of "nn_XXX".
PS: nds_DE and nds_NL are valid locales...:-)
signature.asc
Description: Digital signature
Another raw idea for lintian check: variable substitution in debconf templates
Yet another idea popping up in my mind. I'm in a lintian mood today..:)
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.
I'm sorry for not being technically able to provide the appropriate
patch to lintian for this but that could deserve some attention.
The lintian error message (this is an error, imho) should instruct the
package maintainer to contact the translator listed in
"Last-Translator:" in order to have him|her correct this mistake.
Thoughts? I voluntarily didn't report this as a wishlist bug against
lintian because it needs some initial discussion, probably.
--
signature.asc
Description: Digital signature
Bug#459293: lintian: partially-translated-question is misleading and not really useful
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. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.14 package building tools for Debian ii file4.21-4 Determines file type using "magic" ii gettext 0.17-2 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-1 parse Debian changelogs and output ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.0-4 on-line manual pager ii perl [libdigest-md5 5.8.8-12 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339829: "test for best-practice homepage field" should become "recommend Hompage: field"
forcemerge 444336 339829 thanks Now that "Hompage:" is legal in debian/control, it should be promoted instead of the Homepage pseudo-field in the package's description. Therefore merging these bugs. Hope the lintian maintainers won't mind..:-) -- signature.asc Description: Digital signature
Bug#416140: lintian: Should warn about the needed debconf version for packages using "error" debconf templates
> Thanks, Christian! > > There's another, related bug for better debconf dependency management that > I need to look at which should make this even easier to implement, so I'm > hopeful that it will make it into the next release. > > Do you know what verson of cdebconf introduced this feature? From the changelog, this is 0.39 (Sun, 27 Jul 2003, so between woody and sarge). signature.asc Description: Digital signature
Bug#416140: lintian: Should warn about the needed debconf version for packages using "error" debconf templates
Package: lintian Version: 1.23.28 Severity: normal (debconf maitnainers CC'ed) Some packages use "error" debconf templates (indeed quite often on my suggestion when I launched a campaign to remove useless debconf notes back in September 2006). The support for this has been introduced only in debconf 1.4.69, so lintian should warn maintainers about not version depending on that version of debconf if their debconf templates use the "error" type. Please accept my apologies for not providing a patch for this. I indeed wanted this to be recorded so that someone could come up with a patch some day..:) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages lintian depends on: ii binutils 2.17-3The GNU assembler, linker and bina ii diffstat 1.43-2produces graph of changes introduc ii dpkg-dev 1.13.25 package building tools for Debian ii file 4.20-1Determines file type using "magic" ii gettext0.16.1-1 GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libparse-debianchangel 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-6 The on-line manual pager ii perl [libdigest-md5-pe 5.8.8-7 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368206: lintian: Should not warn for writing style in untranslatable templates
> I let the lintian maintainers mark this bug as wontfix if they agree > with me. I actually don't exactly agree with this. Mostly not because it hurts me, but because I fear this can turn some developers mad at these lintian checks (I guess some are already anyway with this attempt to "enforce" writing style which I take a lot of respnsibility for). So, if there is a code solution to this, please consider it...:-) signature.asc Description: Digital signature
Bug#368206: lintian: Should not warn for writing style in untranslatable templates
Quoting Russ Allbery ([EMAIL PROTECTED]): > Thomas Huriaux <[EMAIL PROTECTED]> writes: > > > There is no way to find in a binary package if the strings are marked as > > translatable. > > Oh, hm, yes. I hadn't realized that, but that makes sense. > > > Using the source package is also a bad idea, as these templates may be > > modified at build time. > > Yeah, and with all the weird build systems out there (yada comes to mind), > trying to find the templates in the source package can be quite hard. Some intermediate way would be to exclude templates with "For internal use only" and actually amend the DevRef to specifically request developers to use this exact description as short description for templates that do not need translation (and otpionnally add more stuff in the long description) signature.asc Description: Digital signature
Bug#368206: lintian: Should not warn for writing style in untranslatable templates
Package: lintian Version: 1.23.21 Severity: minor CC'ing Thomas as I know he's the one who sent the patch. Lintian currently warns for writing style in some templates it shouldn't: W: passwd: malformed-prompt-in-templates passwd/root-password-crypted The offending template is: # This template is for D-I purposes and should allow # preseeding the root password with a crypted password rather than cleartext Template: passwd/root-password-crypted Type: password Description: For internal use only So, I hereby suggest that lintian does NOT check the wording of strings that are contained in an untranslatable template, because this is most of the time meant for not being displayed. In any case, thanks a lot for the work on lintian and thanks A LOT for incorporating Thomas suggested changes. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages lintian depends on: ii binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina ii diffstat 1.41-1 produces graph of changes introduc ii dpkg-dev 1.13.19 package building tools for Debian ii file 4.17-1 Determines file type using "magic" ii gettext 0.14.5-4GNU Internationalization utilities ii intltool-debian 0.34.2+20060512 Help i18n of RFC822 compliant conf ii libparse-debianchang 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-3 The on-line manual pager ii perl [libdigest-md5- 5.8.8-4 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lintian warnings on setuid/setgid programs in the shadow package
While preparing a NMU for shadow (with the maintainer, Karl Ramm <[EMAIL PROTECTED]>, consent), I noticed a few lintian warnings for setuid/setgid programs which are of course deliberately set as such: W: passwd: setgid-binary usr/bin/chage 2755 root/shadow W: passwd: setuid-binary usr/bin/chfn 4755 root/root W: passwd: setuid-binary usr/bin/chsh 4755 root/root W: passwd: setgid-binary usr/bin/expiry 2755 root/shadow W: passwd: setuid-binary usr/bin/gpasswd 4755 root/root W: passwd: setuid-binary usr/bin/passwd 4755 root/root I suppose that a lintian exception for these is needed... --
