Bug#637540: lintian: bad-distribution-in-changes-file wheezy
Package: lintian Version: 2.5.2~bpo60+1 Severity: normal lintian complains about a bad distribution when a codename (like, say, wheezy or squeeze) is used in changes files as Distribution. Cheers, Julien -- System Information: Debian Release: 6.0.2 APT prefers proposed-updates APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.20.1-16 The GNU assembler, linker and bina ii bzip2 1.0.5-6 high-quality block-sorting file co ii diffstat 1.53-1produces graph of changes introduc ii file 5.04-5Determines file type using magic ii gettext0.18.1.1-3GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg ii libclass-accessor-perl 0.34-1Perl module that automatically gen ii libdpkg-perl 1.15.8.11 Dpkg perl modules ii libemail-valid-perl0.184-1 Perl module for checking the valid ii libipc-run-perl0.89-1Perl module for running processes ii libparse-debianchangel 1.1.1-2.1 parse Debian changelogs and output ii libtimedate-perl 1.2000-1 collection of modules to manipulat ii liburi-perl1.58-1module to manipulate and access UR ii locales2.11.2-10 Embedded GNU C Library: National L ii man-db 2.5.7-8 on-line manual pager ii perl [libdigest-sha-pe 5.10.1-17squeeze2 Larry Wall's Practical Extraction ii unzip 6.0-4 De-archiver for .zip files lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch2.20.1-16 Binary utilities that support mult ii dpkg-dev 1.15.8.11 Debian package development tools ii libhtml-parser-perl 3.68-1 collection of modules that parse H ii libtext-template-perl 1.45-1 Text::Template perl module ii man-db2.5.7-8on-line manual pager ii xz-utils 5.0.0-2XZ-format compression utilities -- 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/20110812121342.ga17...@radis.liafa.jussieu.fr
[Draft] Bits from the lintian maintainers
Hi See attached document; comments welcome :) ~Niels Topics: - Vendor profiles - Configuration file changes - Changes to Lintian options - Other improvements - Known bugs and issues - Help us help you Vendor Profiles === Starting with version 2.5.2, Lintian can now be asked to produce the same results as it would have on an Ubuntu machine or on the FTP-master server, when dak checks packages for auto-rejects tags. Using vendor profiles, it is now possible for vendors to choose any subset of Lintian tags that matches their needs. Furthermore these profiles can be used to alter the severity of any given tag or even declare them as non-overridable. By default, Lintian will query dpkg-vendor to determine the best profile for the given vendor, so developers only need to explicitly state the requested profile when they need a special profile. The default Debian profile inherits the non-overridable tags from the ftp-master auto-reject profile. Note: As in the past with the -F option, the ftp-master auto-reject profile contains the list of tags that were auto-rejects at the time Lintian was released. Therefore, the profile may be out-dated and you can find an update to date list at [1]. [1] http://ftp-master.debian.org/static/lintian.tags Configuration file changes == Lintian since 2.5.1 supports reading some options in the configuration file. With this, you no longer have to pass up to 3 options to get Lintian to display all the tags you want. Version 2.5.2 featured a very important bug fix to this new feature. Namely, Lintian now ships proper documentation on the configuration file, so you no longer have to guess how to add options. Please refer to man lintian for more information. Changes to Lintian options == The command-line options has seen a number of changes since the 2.5.0~rc1. The following options have been removed or has been deprecated and will be removed soon: --unpack-level (removed in 2.5.0~rc3) In Lintian 2.3.1 unpack level 2 disappeared. Since then --unpack and --remove has largely made --unpack-level redundant. Unpack level 1 was finally completely removed in 2.5.2. --checksums (deprecated in 2.5.1) Lintian will now always verify the checksums listed in changes files. --packages-file (deprecated in 2.5.2) This option was used to tell Lintian was packages to process via a file with a special syntax. It primary use was for the lintian.debian.org setup. This has been replaced by --packages-from-file with has a simplier syntax. The following options has been added: --no-cfg (added in 2.5.1) This prevents Lintian from loading any configuration file. The option completely overrules any attempts to request a config file (e.g. --cfg or LINTIAN_CFG). --profile (added in 2.5.2) This allows you to choose which vendor profile should be used. Please see the Vendor profiles section above or refer to the Lintian User Manual for the full details of vendor profiles. --packages-from-file (added in 2.5.2) This asks Lintian to read the files to process from a file (or stdin by using -). Lintian will consider each line in the input as the name of a file to process. This is a lot more find $query |-friendly and has replaced the old option --packages-file. Other improvements == These days Linian * has a test coverage of over 75% for tags 687 of the 915 tags that Lintian can currently emit are now covered in the new test-suite. This gives a tag coverage on 75.08% and if the legacy test-suite is included, the coverage hits 815 tags or 89.07%. * processes related packages together Since 2.5.0~rc3 Lintian has grouped related packages and processed them together. With this Lintian can now do things like check if a manpage is in a direct dependency. * supports architecture specific overrides In some cases tags may only appear on certain architectures and since files must be byte-for-byte-identical in Multi-Arch: same packages, Lintian now has architecture specific overrides. For now it only supports simple architectures in the overrides. * has a smarter test suite The 4 test suites covering tags now all supports templates and imports a clean package skeleton. This has allowed a considerable reduction in copy/waste in the tests and gives better results. Known bugs and issues = * Overrides for non-overridable tags are silently dropped. If a package has an override for a tag that cannot be overriden (with the given profile), the override is silently ignored. The fix for this is scheduled for 2.5.3. * Unknown fields in profiles are silently ignored. If a profile contains an unknown field, Lintian will silently ignore the field. This fix for this is scheduled for 2.5.3.
Re: [Draft] Bits from the lintian maintainers
Niels Thykier ni...@thykier.net writes: * processes related packages together Since 2.5.0~rc3 Lintian has grouped related packages and processed them together. With this Lintian can now do things like check if a manpage is in a direct dependency. ...in a direct dependency built from the same source package. Unless that feature is much neater than I think it is. :) * supports architecture specific overrides architecture-specific In some cases tags may only appear on certain architectures and since files must be byte-for-byte-identical in Multi-Arch: same packages, Lintian now has architecture specific overrides. For now it only supports simple architectures in the overrides. ...in the overrides, not wildcards like linux-any. (Some people probably won't know what you mean here, since architecture wildcards are still fairly new.) This otherwise looks great to me. And on a personal note, thank you *so* much for all the work that you've been doing on Lintian. I've often had the experience with other open source projects of personally running out of time and seeing the project stagnate, which usually makes me feel even worse about not having enough time and is very depressing. It's been a delight to see things moving along with such wonderful progress! It's made it much less depressing to be temporarily trapped in a deluge of work, and is keeping me feeling enthusiastic about the chance to get back to work on Lintian again. (My current major work project is supposed to go into beta release on September 1st, after which I have a bunch of documentation to write and then am on vacation for chunks of September and most of October, and then I have great hopes to be back and able to do more Debian work. At: http://git.eyrie.org/?p=kerberos/webauth.git is what I've been working on, for anyone who's idly curious.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vcu24nxv@windlord.stanford.edu
Bug#637540: lintian: bad-distribution-in-changes-file wheezy
Julien Cristau jcris...@debian.org writes: lintian complains about a bad distribution when a codename (like, say, wheezy or squeeze) is used in changes files as Distribution. This was intentional, since my understanding was that stable, stable-security, or stable-proposed-updates was supposed to be used instead and such distributions won't work properly. If they will, we can certainly change that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zkje4od2@windlord.stanford.edu
Bug#637540: lintian: bad-distribution-in-changes-file wheezy
On Fri, Aug 12, 2011 at 08:54:17 -0700, Russ Allbery wrote: Julien Cristau jcris...@debian.org writes: lintian complains about a bad distribution when a codename (like, say, wheezy or squeeze) is used in changes files as Distribution. This was intentional, since my understanding was that stable, stable-security, or stable-proposed-updates was supposed to be used instead and such distributions won't work properly. If they will, we can certainly change that. I prefer to use the codenames since they don't suddenly change meanings around release time. And they get mapped to the right thing by dak in the end, anyway. Cheers, Julien -- 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/20110812171102.gw32...@radis.liafa.jussieu.fr
Re: [Draft] Bits from the lintian maintainers
On Aug 12, 2011, at 18:03, Russ Allbery wrote: Niels Thykier ni...@thykier.net writes: This otherwise looks great to me. And on a personal note, thank you *so* much for all the work that you've been doing on Lintian. I've often had the experience with other open source projects of personally running out of time and seeing the project stagnate, which usually makes me feel even worse about not having enough time and is very depressing. It's been a delight to see things moving along with such wonderful progress! It's made it much less depressing to be temporarily trapped in a deluge of work, and is keeping me feeling enthusiastic about the chance to get back to work on Lintian again. +1 (My current major work project is supposed to go into beta release on September 1st, after which I have a bunch of documentation to write and then am on vacation for chunks of September and most of October, and then I have great hopes to be back and able to do more Debian work. At: http://git.eyrie.org/?p=kerberos/webauth.git is what I've been working on, for anyone who's idly curious.) Interesting. :-) I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. Regards, Jeremiah -- 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/82741958-a5f5-47a9-b55d-97ea8286f...@jeremiahfoster.com
Re: [Draft] Bits from the lintian maintainers
Jeremiah Foster jerem...@jeremiahfoster.com writes: I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? The newer Lintian modules (the stuff under lib/Lintian) should all have POD documentation, hopefully -- if not, it's a bug. I never wrote documentation for the modules in lib that haven't moved under Lintian since normally the API of the older modules is dodgy and should be redone as part of the namespace move to Lintian::*, so writing POD for the previous API seemed like a waste. The checks themselves do indeed not have POD. I usually think of POD more as end-user documentation, so am not sure how helpful it would be, but if people would find it so, it may be a good way to document the internals more. (Although one should also think about what should instead be moved into a module instead of documented in-place in the check scripts.) I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. That's probably a good idea, since among other things it would let us generate an HTML version to stick on lintian.debian.org. I have Perl scripts that do that for text documentation, but the results of converting POD are usually a bit better. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87zkje1khf@windlord.stanford.edu
Re: [Draft] Bits from the lintian maintainers
On Aug 12, 2011, at 21:36, Jeremiah Foster wrote: I've got a question regarding the various lintian modules. I'm a command line person and often use tools like perldoc to read the documentation that is in with code. Lintian does seem to use I meant doesn't of course. :} plain old documentation very much which I think is too bad. It is considered a perl best practice. I'm happy to add that type of pod to the modules and the scripts as I come across the need. Is that useful? I'd also like to move the README.Developer from plain text to pod while it is still early. pod can get translated into markdown and Mediawiki markup as well as html. Regards, Jeremiah -- 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/82741958-a5f5-47a9-b55d-97ea8286f...@jeremiahfoster.com -- 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/4181e7b0-52d6-44f7-90e1-7aee5aa2a...@jeremiahfoster.com
Example of proposed pod usage (with patch)
Here is an example of how I think pod might work;
---
README.developers |6 -
frontend/lintian | 60 ++--
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/README.developers b/README.developers
index dc1edd0..ca4b206 100644
--- a/README.developers
+++ b/README.developers
@@ -1,4 +1,6 @@
-README.Developers for the Lintian tool
+=pod
+
+Readme.Developers for the Lintian tool
---
Lintian dissects Debian packages and tries to find bugs and policy
@@ -13,3 +15,5 @@ directory frontend. This directory holds the lintian
executable.
This is what gets called when a user calls lintian. The frontend
then calls the lintian checks which run over the Debian package
that Lintian is checking.
+
+=end
diff --git a/frontend/lintian b/frontend/lintian
index 0625b61..907e747 100755
--- a/frontend/lintian
+++ b/frontend/lintian
@@ -1,27 +1,45 @@
#!/usr/bin/perl -w
-# {{{ Legal stuff
-# Lintian -- Debian package checker
-#
-# Copyright (C) 1998 Christian Schwarz and Richard Braakman
-#
-# This program is free software. It is distributed under the terms of
-# the GNU General Public License as published by the Free Software
-# Foundation; either version 2 of the License, or (at your option) any
-# later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, you can find it on the World Wide
-# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
-# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
-# MA 02110-1301, USA.
-# }}}
+
+=head1 NAME
+
+Lintian -- Debian package checker
+
+=over 2
+
+=item ./frontend/lintian
+
+=back
+
+=head1 LEGAL
+
+=over 2
+
+Copyright (C) 1998 Christian Schwarz and Richard Braakman
+
+This program is free software. It is distributed under the terms of
+the GNU General Public License as published by the Free Software
+Foundation; either version 2 of the License, or (at your option) any
+later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, you can find it on the World Wide
+Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+MA 02110-1301, USA.
+
+=back
+
+=cut
+
+
# {{{ libraries and such
+
use strict;
use warnings;
--
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/20110812203406.ga5...@shadowfax.dlinkddns.com
Bug#637590: [checks/conffiles] merge with checks/etcfiles
Package: lintian
Version: 2.5.2
Severity: wishlist
Tags: patch
checks/conffiles and checks/etcfiles are both very short and there's
certain amount of code duplication between them. I propose to merge them
in to a single check.
--
Jakub Wilk
diff --git a/checks/conffiles b/checks/conffiles
--- a/checks/conffiles
+++ b/checks/conffiles
@@ -1,6 +1,7 @@
# conffiles -- lintian check script -*- perl -*-
# Copyright (C) 1998 Christian Schwarz
+# Copyright (C) 2000 Sean 'Shaleh' Perry
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -33,40 +34,55 @@
my $cf = $info-control('conffiles');
-# conffiles?
-unless (-f $cf) {
-return 0;
-}
my %conffiles = ();
-open(IN, '', $cf) or fail(cannot open $cf for reading: $!);
-while (IN) {
-chop;
-next if m/^\s*$/;
+if (-f $cf) {
-unless (m,^/,) {
- tag 'relative-conffile', $_;
- $_ = '/' . $_;
+open(IN, '', $cf) or fail(cannot open $cf for reading: $!);
+while (IN) {
+ chop;
+ next if m/^\s*$/;
+
+ unless (m,^/,) {
+ tag 'relative-conffile', $_;
+ $_ = '/' . $_;
+ }
+ my $file = $_;
+ $file =~ s@^/++@@o;
+ $conffiles{$file}++;
+
+ if ($conffiles{$file} 1) {
+ tag 'duplicate-conffile', $file;
+ }
+
+ if (m,^/usr/,) {
+ tag 'file-in-usr-marked-as-conffile', $file;
+ } else {
+ unless (m,^/etc/,) {
+ tag 'non-etc-file-marked-as-conffile', $file;
+ }
+ }
+
}
-my $file = $_;
-$file =~ s@^/++@@o;
-$conffiles{$file}++;
-
-if ($conffiles{$file} 1) {
- tag 'duplicate-conffile', $file;
-}
-
-if (m,^/usr/,) {
- tag 'file-in-usr-marked-as-conffile', $file;
-} else {
- unless (m,^/etc/,) {
- tag 'non-etc-file-marked-as-conffile', $file;
- }
-}
+close(IN);
}
-close(IN);
+
+# Read package contents...
+foreach my $file (@{$info-sorted_index}) {
+my $index_info = $info-index-{$file};
+next unless $file =~ m,^etc, and $index_info-{type}=~ m/^[-h]/;
+
+# If there is a /etc/foo, it must be a conffile (with a few exceptions).
+if (not exists($conffiles{$file})
+ and $file !~ m,/README$,
+ and $file ne 'etc/init.d/skeleton'
+ and $file ne 'etc/init.d/rc'
+ and $file ne 'etc/init.d/rcS') {
+ tag 'file-in-etc-not-marked-as-conffile', $file;
+}
+}
}
diff --git a/checks/conffiles.desc b/checks/conffiles.desc
--- a/checks/conffiles.desc
+++ b/checks/conffiles.desc
@@ -37,3 +37,10 @@
Usually, this is because debhelper (dh_installdeb, compat level 3 or higher)
will add any files in your package located in /etc automatically to the list
of conffiles, so if you do that manually too, you'll get duplicates.
+
+Tag: file-in-etc-not-marked-as-conffile
+Severity: serious
+Certainty: certain
+Ref: policy 10.7
+Info: Files in tt/etc/tt must be marked conffiles if they are included
+ in a package. Otherwise they should be created by maintainer scripts.
diff --git a/checks/etcfiles b/checks/etcfiles
deleted file mode 100644
--- a/checks/etcfiles
+++ /dev/null
@@ -1,66 +0,0 @@
-# etcfiles -- lintian check script -*- perl -*-
-
-# Copyright (C) 2000 by Sean 'Shaleh' Perry
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, you can find it on the World Wide
-# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
-# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
-# MA 02110-1301, USA.
-
-package Lintian::etcfiles;
-use strict;
-use warnings;
-
-use Util;
-use Lintian::Tags qw(tag);
-
-sub run {
-
-my $pkg = shift;
-my $type = shift;
-my $info = shift;
-
-my %conffiles;
-
-my $conffiles = $info-control('conffiles');
-
-# load conffiles
-if (open(IN, '', $conffiles)) {
-while (IN) {
- chop;
- next if m/^\s*$/o;
- s,^/,,;
- $conffiles{$_} = 1;
-}
-close(IN);
-}
-
-# Read package contents...
-foreach my $file (@{$info-sorted_index}) {
-my $index_info = $info-index-{$file};
-next unless $file =~ m,^etc, and $index_info-{type}=~ m/^[-h]/;
-
-# If there is a /etc/foo, it must be a conffile (with a few exceptions).
-if (not exists($conffiles{$file})
- and $file !~ m,/README$,
- and $file ne 'etc/init.d/skeleton'
- and $file ne 'etc/init.d/rc'
- and $file ne 'etc/init.d/rcS') {
- tag 'file-in-etc-not-marked-as-conffile', $file;
-}
-}
-
-}
-
-1;
diff --git a/checks/etcfiles.desc b/checks/etcfiles.desc
deleted file mode 100644
--- a/checks/etcfiles.desc
+++ /dev/null
@@
Bug#637595: lintian: please use LC_ALL instead of LANG
Package: lintian
Version: 2.5.2
Tags: patch
In a few places, lintian sets the LANG variable to force a particular
locale. This is incorrect, as LANG determines the locale only in the
absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES,
LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables.[0] The LC_ALL
variable should be used instead.
The attached patch should fix this problem. (I'm not sure what was the
purpose of setting LANG=en_US.UTF-8 and LC_CTYPE=C in private/runtests,
but apparently using LC_ALL=C there doesn't break anything.)
[0] http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html#tag_002_002
--
Jakub Wilk
# HG changeset patch
# Parent afd9713258f4a63cbd123dbbe544a4216f2cf28d
diff --git a/checks/infofiles b/checks/infofiles
--- a/checks/infofiles
+++ b/checks/infofiles
@@ -89,7 +89,7 @@
fail(cannot fork: $!);
} elsif ($pid == 0) {
my $f = quotemeta($info-unpacked($file));
- my %newenv = (LANG = 'C', PATH = $ENV{PATH},
+ my %newenv = (LC_ALL = 'C', PATH = $ENV{PATH},
LOCPATH = $ENV{LOCPATH});
undef %ENV;
%ENV = %newenv;
diff --git a/checks/manpages b/checks/manpages
--- a/checks/manpages
+++ b/checks/manpages
@@ -218,7 +218,7 @@
if (not defined $pid) {
fail(cannot run lexgrog: $!);
} elsif ($pid == 0) {
- my %newenv = (LANG = 'en_US.UTF-8', PATH = $ENV{PATH},
+ my %newenv = (LC_ALL = 'en_US.UTF-8', PATH = $ENV{PATH},
LOCPATH = $ENV{LOCPATH});
undef %ENV;
%ENV = %newenv;
@@ -252,7 +252,7 @@
if (not defined $pid) {
fail(cannot run man -E UTF-8 -l: $!);
} elsif ($pid == 0) {
- my %newenv = (LANG = 'en_US.UTF-8', PATH = $ENV{PATH},
+ my %newenv = (LC_ALL = 'en_US.UTF-8', PATH = $ENV{PATH},
MANWIDTH = 80, LOCPATH = $ENV{LOCPATH});
undef %ENV;
%ENV = %newenv;
diff --git a/checks/manpages.desc b/checks/manpages.desc
--- a/checks/manpages.desc
+++ b/checks/manpages.desc
@@ -174,7 +174,7 @@
Debugging in the groff manual.
.
To test this for yourself you can use the following command:
- LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l lt;filegt; gt;/dev/null
+ LC_ALL=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l lt;filegt; gt;/dev/null
Tag: manpage-has-errors-from-pod2man
Severity: normal
diff --git a/checks/po-debconf b/checks/po-debconf
--- a/checks/po-debconf
+++ b/checks/po-debconf
@@ -170,7 +170,7 @@
system_env(msgfmt -o /dev/null \Q$debfiles/po/$file\E 2/dev/null) == 0
or tag 'invalid-po-file', debian/po/$file;
- my $stats = `LANG=C msgfmt -o /dev/null --statistics \Q$debfiles/po/$file\E 21`;
+ my $stats = `LC_ALL=C msgfmt -o /dev/null --statistics \Q$debfiles/po/$file\E 21`;
if (!$full_translation $stats =~ m/^\w+ \w+ \w+\.$/) {
$full_translation = 1;
}
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -61,8 +61,8 @@
build-stamp: $(neededfiles) $(docsource) $(testtarget)
@echo running build
dh_testdir
- cd doc LANG=C docbook2html -V %use-id-as-filename% -o lintian.html lintian.xml
- cd doc LANG=C jw -b txt lintian.xml
+ cd doc LC_ALL=C docbook2html -V %use-id-as-filename% -o lintian.html lintian.xml
+ cd doc LC_ALL=C jw -b txt lintian.xml
mkdir man/man1/
private/generate-lintian-pod | \
pod2man --name lintian --center Debian Package Checker --section=1 man/man1/lintian.1
diff --git a/lib/Util.pm b/lib/Util.pm
--- a/lib/Util.pm
+++ b/lib/Util.pm
@@ -235,7 +235,7 @@
my ($file, $type, $pkg) = @_;
my $non_utf8 = 0;
- open (ICONV, '-|', env LANG=C iconv -f utf8 -t utf8 \Q$file\E 21)
+ open (ICONV, '-|', env LC_ALL=C iconv -f utf8 -t utf8 \Q$file\E 21)
or fail(failure while checking encoding of $file for $type package $pkg);
my $line = 1;
while (ICONV) {
diff --git a/private/refresh-archs b/private/refresh-archs
--- a/private/refresh-archs
+++ b/private/refresh-archs
@@ -26,7 +26,7 @@
exit 0
fi
-export LANG=C
+export LC_ALL=C
dpkg_version=$(dpkg-architecture --version | head -n1)
diff --git a/private/refresh-locale-codes b/private/refresh-locale-codes
--- a/private/refresh-locale-codes
+++ b/private/refresh-locale-codes
@@ -54,7 +54,7 @@
EOF
-export LANG=C
+export LC_ALL=C
{
isoquery -i 639
diff --git a/private/runtests b/private/runtests
--- a/private/runtests
+++ b/private/runtests
@@ -15,8 +15,7 @@
TAG=yes
fi
-LANG=en_US.UTF-8
-LC_COLLATE=C
+LC_ALL=C
LINTIAN_ROOT=
LINTIAN_PROFILE=debian
LINTIAN_INTERNAL_TESTSUITE=1
@@ -25,8 +24,7 @@
[ $TEST_WORK_DIR ] || TEST_WORK_DIR=debian/test-out
-export LANG
-export LC_COLLCATE
+export LC_ALL
export LINTIAN_ROOT
export LINTIAN_PROFILE
export LINTIAN_INTERNAL_TESTSUITE
Bug#633779: lintian: validate DEP-5 debian/copyright files
* Niels Thykier ni...@thykier.net, 2011-07-18, 00:34: I attached a (preliminary?) patch adding support for very basic DEP-5 validation. Beware, tag descriptions could use some love. ;) Hi Thanks for looking into this. Personally I am considering if this should be moved into its own check. While it is related to the copyright-file check I think a DEP-5 check could easily deserve its own check file. Particularly it may keep the logic simple(r) and the DEP-5 check will most likely be extended in the future (e.g. to check the other paragraphs). As far as I can see, lintian currently checks only copyright files in binary packages, not in source packages. However, to properly validate a DEP-5 copyright file, you need access the source package. So perhaps it'd make sense to have a source-copyright-file check and move DEP-5 stuff there? -- Jakub Wilk -- 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/20110812225707.ga6...@jwilk.net
