[SCM] Debian package checker branch, master, updated. 2.5.2-16-g2860a9b
The following commit has been merged in the master branch:
commit 2860a9b028dcdc137d49d634cc3c20d1aa30b503
Author: Niels Thykier ni...@thykier.net
Date: Sun Aug 14 15:27:16 2011 +0200
Use croak instead of fail in Lintian::Collect::Package
diff --git a/debian/changelog b/debian/changelog
index 9a5b605..193238e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -32,6 +32,8 @@ lintian (2.5.3) UNRELEASED; urgency=low
LANG.
* lib/Lintian/Collect/Source.pm:
+ [NT] Removed a requirement for fields that was not needed.
+ * lib/Lintian/Collect/Package.pm:
++ [JW,NT] Replace use of fail with croak. (Closes: #637741)
* lib/Lintian/Profile.pm:
+ [NT] Reject profiles containing an unknown field.
diff --git a/lib/Lintian/Collect/Package.pm b/lib/Lintian/Collect/Package.pm
index 93f8095..c535450 100644
--- a/lib/Lintian/Collect/Package.pm
+++ b/lib/Lintian/Collect/Package.pm
@@ -43,12 +43,12 @@ sub file_info {
my %file_info;
# sub file_info Needs-Info file-info
open(my $idx, '', $base_dir/file-info)
-or fail(cannot open $base_dir/file-info: $!);
+or croak cannot open $base_dir/file-info: $!;
while ($idx) {
chomp;
m/^(.+?)\x00\s+(.*)$/o
-or fail(an error in the file pkg is preventing lintian from
checking this package: $_);
+or croak an error in the file pkg is preventing lintian from
checking this package: $_;
my ($file, $info) = ($1,$2);
$file =~ s,^\./,,o;
@@ -114,10 +114,10 @@ sub _fetch_index_data {
my (%idxh, %dir_counts);
my $num_idx;
open my $idx, '', $base_dir/$index
-or fail(cannot open index file $base_dir/$index: $!);
+or croak cannot open index file $base_dir/$index: $!;
if ($indexown) {
open $num_idx, '', $base_dir/$indexown
-or fail(cannot open index file $base_dir/$indexown: $!);
+or croak cannot open index file $base_dir/$indexown: $!;
}
while ($idx) {
chomp;
@@ -132,9 +132,9 @@ sub _fetch_index_data {
# If we have a numeric owner index file, read that as well
my $numeric = $num_idx;
chomp $numeric;
-fail('cannot read index file $indexown') unless defined $numeric;
+croak 'cannot read index file $indexown' unless defined $numeric;
my ($owner_id, $name_chk) = (split(' ', $numeric, 6))[1, 5];
-fail(mismatching contents of index files: $name $name_chk)
+croak mismatching contents of index files: $name $name_chk
if $name ne $name_chk;
($file{uid}, $file{gid}) = split '/', $owner_id, 2;
}
--
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
Archive: http://lists.debian.org/e1qsapu-000497...@vasks.debian.org
Processed: limit source to lintian, tagging 637741
Processing commands for cont...@bugs.debian.org: #lintian (2.5.3) UNRELEASED; urgency=low # # * lib/Lintian/Collect/Package.pm: #+ [JW,NT] Replace use of fail with croak. (Closes: #637741) # limit source lintian Limiting to bugs with field 'source' containing at least one of 'lintian' Limit currently set to 'source':'lintian' tags 637741 + pending Bug #637741 [lintian] [lib/Lintian/Collect/Package.pm] uses fail without importing it Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 637741: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637741 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13133288824962.transcr...@bugs.debian.org
Re: [SCM] Debian package checker branch, master, updated. 2.5.2-11-g39af0d7
On 2011-08-14 00:56, Russ Allbery wrote:
Niels Thykier ni...@thykier.net writes:
Turns out this particular these two were not Perlcritic issues (I
applied these fixes from my memory of previous Perlcritic issues).
Oh! Okay. I'm actually surprised on the variable one, as I've seen
things like that from perlcritic before.
It is possible that the warning is there, but was disabled by our
perlcritic settings. Raphael deployed a .perlcriticrc using a whitelist
(and one in t/scripts/critic.t).
So the my vs. our, I seem to have confused our with use vars in
terms of Perlcritic warnings. As for my vs. our, it is my
understanding that our makes the variable public[0] and it seems to
me these variables are not actually intended to be used outside of
checks/standards-version.
It does, sort of, in the sense that some other module could access those
variables from inside the namespace for that check, and my does prevent
that. So I suppose this is more of a style thing. I always use our for
global constants or things initialized at startup, combined with the
all-caps naming convention. I'm not sure if there's an official style, or
what's the most common.
I usually buy the All caps as global variables, but I still like to
differ between exported/public variables and internal global variables.
I personally prefer the checks being completely self-contained and
would like to see shared constants (if any) moved to a separate module
that declares them as exported. Partly because we still have code like:
# If we have an unknown architecture, pretend that all [...]
if ($arch ne 'all' and not exists($ARCH_REGEX{$arch})) {
debug_msg(1, Unknown architecture: $arch);
$ARCH_REGEX{$arch} = qr/./;
}
(checks/binaries)
My second reason is that I like to know that if I want to change (the
format of) a variable, I know I only have to check the current file and
nothing else.
A final note on it, is that we had variables in frontend/lintian
declared as our without being all caps... and one of them was actually
used in a check (the --checksums variable).
If we do formalize a code-style, I hope we can agree that this is not
good. :)
I suppose another alternative would be use constant, at least in some
cases, although that creates a sub that then doesn't have a type prefix,
and I think those look kind of strange. But that may just be because I've
been writing Perl for too long. :)
I normally like constants, but some how they feel wrong in perl...
like a second-grade citizen or so. To use a constant in a regex you
have to do stuff like ${\CONSTANT}. .
On the other issue, I thought the $C, @C-thing was covered by the
re-use of same variable in lexical scope, but it turns out it isn't
(probably due to the types being different).
Ah. Yes. Each type of variable has its own separate namespace.
I can see the idea behind it now, sort of like a C-string where you
can process the string as a whole (strcmp(s, text)) or individual
characters (s[0]). I guess the perl way of doing that is to declare two
variables with same name and different type.
Yeah, or at least that's what I've always done in the past.
All right, I am ready to buy that approach in moderate doses. Maybe it
is a familiarity thing. Perhaps we can declare both variables at the
same place.
In the given case I can see the use of this. That being said, I have
my concerns blessing wide-spread use of this. You may remember I got a
bit confused with:
$checks or ($checks = join(',',keys %check_info));
[...]
$checks{$c} = 1;
from frontend/lintian in 2.4.3: $checks was a comma-separated list and
%checks was a hash where the keys were elements from said list.
Yeah. I'm not sure if this is really confusing, or if it's just a
familiarity thing. I use the same name (but a different type) for any set
of variables that all hold exactly the same contents but in a different
data structure, and use a different variable name if the contents may be
different.
Coming from languages where it is not allowed, it is confusing[0]. :)
But when you have coded in Perl for a while it (also) becomes a
familiarity thing.
It broke one of my assumptions; namely a variable is only declared at
most once in any given scope[1]. So when I saw my $checks; in
frontend/lintian, it never crossed my mind to check for my %checks;
which appeared 10-12 lines further down (until Adam pointed it out over
IRC).
In hindsight, I had plenty of pointers to look for a declaration of
%checks (a hashref would have used -{} rather than {} and strict
forbids/croaks on use of non-hashref as hashref, etc.), which is where
the familiarity part kicks in[2].
For newcomers, I think we can save them a bit of confusion by at least
comment when we do reuse the variable name in these cases.
[0] Even perldata agrees with me: XD
This means that $foo and @foo are two different variables. It also
means that $foo[1] is a part of
Re: [SCM] Debian package checker branch, master, updated. 2.5.2-11-g39af0d7
On 2011-08-14 00:11, Jeremiah C. Foster wrote:
[...]
On the other issue, I thought the $C, @C-thing was covered by the
re-use of same variable in lexical scope, but it turns out it isn't
(probably due to the types being different).
I can see the idea behind it now, sort of like a C-string where you
can process the string as a whole (strcmp(s, text)) or individual
characters (s[0]). I guess the perl way of doing that is to declare two
variables with same name and different type.
Yeah, this is exactly what perl does. The sigil is meant to be the mnemonic,
so you know that $ is scalar and @ is array.
So I knew the sigil meant declared its type, but from there to giving
them a separate namespace... I missed that.
In the given case I can see the use of this. That being said, I have
my concerns blessing wide-spread use of this. You may remember I got a
bit confused with:
$checks or ($checks = join(',',keys %check_info));
[...]
$checks{$c} = 1;
from frontend/lintian in 2.4.3: $checks was a comma-separated list and
%checks was a hash where the keys were elements from said list.
It looks like in this case the second $checks is actually a reference to a
hash.
More: http://oreilly.com/catalog/advperl/excerpt/ch01.html
It wasn't... It was an actual hash (and a scalar). There is a longer
version in my reply to Russ's email (or you can checkout 2.4.3 and have
a look at frontend/lintian).
Can you point me to the section on my ($v, @v, %v); in the perl
documentation (not really sure what to look/google for here). I would
like to get a second look on this. :)
Perl has a rich set of datatypes, that URL above describes most of those that
you'll run into, i.e. scalars, arrays, hashes and references to all three.
Right, I know. :) I was looking for the documentation that mentioned
that my $a; can co-exists with my @a; without
conflicts/clashes/shadowing. Russ already pointed out perldata, but
thanks anyhow. :)
Regards,
Jeremiah
~Niels
--
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/4e47db09.4060...@thykier.net
[SCM] Debian package checker branch, master, updated. 2.5.2-17-g316dd97
The following commit has been merged in the master branch:
commit 316dd97dc54ed95685268a2ac0db2245bd9f3da7
Author: Niels Thykier ni...@thykier.net
Date: Sun Aug 14 15:58:43 2011 +0200
Undo part 39af0d7, allow $CURRENT and @CURRENT to co-exists
diff --git a/checks/standards-version b/checks/standards-version
index 135b884..ee70d0d 100644
--- a/checks/standards-version
+++ b/checks/standards-version
@@ -39,9 +39,12 @@ my $STANDARDS =
Lintian::Data-new('standards-version/release-dates', qr/\s+/o);
# by release date. We can also use this to get the current standards version.
my @STANDARDS = sort { $b-[1] = $a-[1] }
map { [ $_, $STANDARDS-value($_) ] } $STANDARDS-all;
-my $CURRENT_VER = $STANDARDS[0][0];
my $CURRENT_DATE = $STANDARDS[0][1];
-my @CURRENT = split(m/\./, $CURRENT_VER);
+
+# In scalar context you get the string (e.g. 3.9.2)
+# and in list context you get it split into pieces (3, 9, 2)
+my $CURRENT = $STANDARDS[0][0];
+my @CURRENT = split(m/\./, $CURRENT);
sub run {
@@ -99,7 +102,7 @@ if (defined $dist $dist ne 'UNRELEASED'
$STANDARDS-known($stdver)
tag 'timewarp-standards-version', ($package $release);
}
-my $tag = $version (current is $CURRENT_VER);
+my $tag = $version (current is $CURRENT);
if (not $STANDARDS-known($stdver)) {
# Unknown standards version. Perhaps newer?
if ( ($major $CURRENT[0])
@@ -110,7 +113,7 @@ if (not $STANDARDS-known($stdver)) {
} else {
tag 'invalid-standards-version', $version;
}
-} elsif ($stdver eq $CURRENT_VER) {
+} elsif ($stdver eq $CURRENT) {
# Current standard. Nothing more to check.
return 0;
} else {
--
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
Archive: http://lists.debian.org/e1qsbhl-0006dn...@vasks.debian.org
Bug#637793: lintian: [PATCH] Improve description of versioned-dependency-satisfied-by-perl
Package: lintian Version: 2.5.2 Severity: minor Tags: patch On Mon, Aug 08, 2011 at 10:40:31AM +0100, Dominic Hargreaves wrote: On Mon, Aug 08, 2011 at 07:02:03AM +, pkg-perl-maintain...@lists.alioth.debian.org wrote: Commit message: move perl 5.14 as a second alternative dependency on libextutils-parsexs-perl 2.21 Closes: #637033 -- FTBFS: unfullfillable first alternative in build-depends Damyan, thanks for fixing this. I think I was distracted by a related lintian warning, which specifically suggests that perl comes first, forgetting the way the autobuilders interpret this. I'll make a note to look at whether the lintian message should be altered. Patch attached. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) From 85c278460c044fccdc3e742475339baf3ca6b3c5 Mon Sep 17 00:00:00 2001 From: Dominic Hargreaves d...@earth.li Date: Sun, 14 Aug 2011 15:42:15 +0100 Subject: [PATCH] Improve description of versioned-dependency-satisfied-by-perl The advice previously given in this description was incorrect for versions of perl only in experimental. --- checks/fields.desc |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/checks/fields.desc b/checks/fields.desc index 425b2d9..82c83e2 100644 --- a/checks/fields.desc +++ b/checks/fields.desc @@ -934,6 +934,12 @@ Info: This package declares an unnecessary versioned dependency versioned dependency a secondary one. . Example: perl (gt;= 5.10.0) | libmodule-build-perl (gt;= 0.26) + . + An exception to this is when the dependency is only satisfied in a + version of perl in experimental. In this case, the dependency on perl + should come second. + . + Example: libextutils-parsexs-perl (gt;= 2.21) | perl (gt;= 5.14) Ref: policy 7.5 Tag: package-superseded-by-perl -- 1.7.5.4
Bug#636994: lintian: add check for deprecated perl libraries (was: #629472)
tags 636994 +patch
thanks
On Sun, Aug 07, 2011 at 05:11:51PM +0100, Dominic Hargreaves wrote:
Thanks for the response; I think you've convinced me that this would
be the best approach, at least to start with.
You're correct that build-time deps will be caught by rebuilds, once
the modules get removed. Ideally in this case we'd have all the
packages fixed well in advance of that; we'd like to be able to drop
them from wheezy+1 without worrying about partial upgrades breaking
things. However, this isn't actually a concern for situations where
the build fails.
I take your point about starting off with the check marked as
experimental, although I would like this check to have the maximum
input before wheezy freezes, so your planned released schedule for
lintian may affect whether I'd like to have that included or not.
I'm filing this as a wishlist bug without patch initially; I had a look
at the lintian git repository and couldn't initially see where the best
place to put such a check would be. If you can give me any hints about
where to start, I'll do so :)
To make this bug report complete, here's a specification for the check:
check in all perl source files in binary packages not depending on
libperl4-corelibs-perl for strings satisfying the following regexp:
/(?:do|require)\s+(?:'|)(?:abbrev|assert|bigfloat|bigint|bigrat|cacheout|complete|ctime|dotsh|exceptions|fastcwd|find|finddepth|flush|getcwd|getopt|getopts|hostname|importenv|look|newgetopt|open2|open3|pwd|shellwords|stat|syslog|tainted|termcap|timelocal|validate)\.pl(?:'|)/
Tag: uses-perl4-libs
Severity: important
Certainty: possible
Experimental: yes
Info: This package includes perl programs using obsoleted perl 4-era
libraries. These libraries have been deprecated in perl in 5.14, and
are likely to be removed from the core in perl 5.16. Please either
remove references to these libraries, or add a dependency on
libperl4-corelibs-perl | perl ( 5.12.3-7) to this package.
Okay, I had a stab at implementing this. It involved a lot of guesswork
and cargo-culting, but it appears to work. Patch attached. Please do
let me know if I can do anything to improve the patch.
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
From c3c6d998bd623d5b4968a17db44daab9e0e479a1 Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves d...@earth.li
Date: Sun, 14 Aug 2011 16:22:14 +0100
Subject: [PATCH] Add new perl4 libs checks
These new checks add the following tags:
- perl-module-uses-perl4-libs-without-dep
- script-uses-perl4-libs-without-dep
Closes: #636994
---
checks/perl_modules | 82 +
checks/perl_modules.desc | 15 +++
checks/scripts| 11 +
checks/scripts.desc |9
collection/perl_modules | 59 +
collection/perl_modules.desc |7 +++
lib/Lintian/Collect/Binary.pm | 20 ++
profiles/debian/main.profile |4 +-
8 files changed, 205 insertions(+), 2 deletions(-)
create mode 100644 checks/perl_modules
create mode 100644 checks/perl_modules.desc
create mode 100755 collection/perl_modules
create mode 100644 collection/perl_modules.desc
diff --git a/checks/perl_modules b/checks/perl_modules
new file mode 100644
index 000..38f5496
--- /dev/null
+++ b/checks/perl_modules
@@ -0,0 +1,82 @@
+# perl-modules -- lintian check script -*- perl -*-
+#
+# This is probably the right file to add a check for the use of
+# set -e in bash and sh scripts.
+#
+# Copyright (C) 1998 Richard Braakman
+# Copyright (C) 2002 Josip Rodin
+# Copyright (C) 2011 Dominic Hargreaves
+#
+# 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::perl_modules;
+use strict;
+use warnings;
+
+use lib $ENV{'LINTIAN_ROOT'}/checks/;
+
+use Lintian::Relation;
+use Lintian::Tags qw(tag);
+
+sub run {
+
+my $pkg = shift;
+my $type = shift;
+my $info = shift;
+
+foreach (@{$info-sorted_index}) {
+next if $_ eq '';
+my $index_info = $info-index-{$_};
+my $operm = $index_info-{operm};
+next unless ($index_info-{type} =~ m,^[-h], and ($operm 01 or
+ $operm 010 or
Processed: Re: Bug#636994: lintian: add check for deprecated perl libraries (was: #629472)
Processing commands for cont...@bugs.debian.org: tags 636994 +patch Bug #636994 [lintian] lintian: add check for deprecated perl libraries (was: #629472) Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 636994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636994 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.131334109331406.transcr...@bugs.debian.org
[SCM] Debian package checker branch, master, updated. 2.5.2-18-g56639e7
The following commit has been merged in the master branch: commit 56639e746e3a4ca461e9c6da275cbbef5712d888 Author: Niels Thykier ni...@thykier.net Date: Sun Aug 14 23:28:01 2011 +0200 Use LC_ALL=C in private/runtests to ensure sorting order diff --git a/private/runtests b/private/runtests index 7fc118f..071f2c3 100755 --- a/private/runtests +++ b/private/runtests @@ -15,7 +15,7 @@ if [ $1 = -t ] ; then TAG=yes fi -LC_ALL=en_US.UTF-8 +LC_ALL=C LINTIAN_ROOT= LINTIAN_PROFILE=debian LINTIAN_INTERNAL_TESTSUITE=1 -- 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 Archive: http://lists.debian.org/e1qsihw-0001x4...@vasks.debian.org
Bug#637819: lintian.debian.org/lintian.log.gz
Package: lintian Severity: wishlist lintian.log is quite big, but it can be compressed easily: even with gzip you can achieve 10-fold size reduction. It would be nice if a compressed version of lintian.log were available for download. -- 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/20110814211618.ga6...@jwilk.net
Bug#633779: lintian: validate DEP-5 debian/copyright files
* Niels Thykier ni...@thykier.net, 2011-08-13, 13:20:
Feel free to add a new separate check if that results in more
maintainable code. :)
Okay, updated patch attached.
--
Jakub Wilk
diff --git a/checks/source-copyright-file b/checks/source-copyright-file
new file mode 100644
--- /dev/null
+++ b/checks/source-copyright-file
@@ -0,0 +1,231 @@
+# source-copyright-file -- lintian check script -*- perl -*-
+
+# Copyright (C) 2011 Jakub Wilk
+#
+# 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::source_copyright_file;
+
+use strict;
+use warnings;
+
+use Lintian::Relation::Version qw(versions_compare);
+use Lintian::Tags qw(tag);
+use Util;
+
+my $dep5_last_normative_change = '0+svn~166';
+my $dep5_last_overhaul = '0+svn~148';
+my %dep5_renamed_fields = (
+'format-specification' = 'format',
+'maintainer' = 'upstream-contact',
+'upstream-maintainer' = 'upstream-contact',
+'contact' = 'upstream-contact',
+'name' = 'upstream-name',
+);
+
+sub run {
+
+my ($pkg, $type, $info) = @_;
+my $pkgs = $info-binaries;
+
+my $copyright_filename = $info-debfiles('copyright');
+
+if (-l $copyright_filename)
+{
+tag 'debian-copyright-is-symlink';
+return;
+}
+
+if (not -f $copyright_filename) {
+tag 'no-debian-copyright';
+$copyright_filename = undef;
+if (keys(%$pkgs) == 1)
+{
+ # If debian/copyright doesn't exist, and the only a single binary
+ # package is built, there's a good chance that the copyright file is
+ # available as debian/pkgname.copyright.
+ $copyright_filename = $info-debfiles((keys(%$pkgs))[0] . '.copyright');
+ if (not -f $copyright_filename or -l $copyright_filename) {
+ $copyright_filename = undef;
+ }
+}
+}
+
+return unless defined $copyright_filename;
+
+$_ = slurp_entire_file($copyright_filename);
+study $_;
+
+my @dep5;
+
+if (m{
+(^ | \n)
+(?i: format(:|[-\s]spec) )
+(?: . | \n\s+ )*
+(?: /dep[5s]?\b | \bDEP-?5\b | [Mm]achine-readable\s(?:license|copyright) | /copyright-format/ | CopyrightFormat | VERSIONED_FORMAT_URL )
+}x)
+{
+# Before trying to parse the copyright as Debian control file, try to
+# determine the format URI.
+my $first_para = $_;
+$first_para =~ s,^#.*,,mg;
+$first_para =~ s,[ \t]+$,,mg;
+$first_para =~ s,^\n+,,g;
+$first_para =~ s,\n\n.*,\n,s;
+$first_para =~ s,\n?[ \t]+, ,g;
+$first_para =~ m,^Format(?:-Specification)?:\s*(.*),mi;
+my $uri = $1;
+$uri =~ s/^([^#\s]+)#/$1/ if defined $uri; # strip fragment identifier
+if (defined $uri) {
+ my $original_uri = $uri;
+ my $version;
+ if ($uri =~ m,\b(?:rev=REVISION|VERSIONED_FORMAT_URL)\b,) {
+ tag 'boilerplate-copyright-format-uri';
+ }
+ elsif ($uri =~ s,http://wiki\.debian\.org/Proposals/CopyrightFormat\b,,) {
+ $version = '0~wiki';
+ $uri =~ m,^\?action=recallrev=(\d+)$, and $version = $version~$1;
+ }
+ elsif ($uri =~ m,^http://dep\.debian\.net/deps/dep5/?$,) {
+ $version = '0+svn';
+ }
+ elsif ($uri =~ s,^http://svn\.debian\.org/wsvn/dep/web/deps/dep5\.mdwn\b,,) {
+ $version = '0+svn';
+ $uri =~ m,^\?(?:\S+)?rev=(\d+)(?:\S+)?$, and $version = $version~$1;
+ }
+ elsif ($uri =~ s,^http://anonscm\.debian\.org/viewvc/dep/web/deps/dep5\.mdwn\b,,) {
+ $version = '0+svn';
+ $uri =~ m,^\?(?:\S+)?revision=(\d+)(?:\S+)?$, and $version = $version~$1;
+ }
+ elsif ($uri =~ m,^http://www\.debian\.org/doc/(?:packaging-manuals/)?copyright-format/(\d+\.\d+)$,) {
+ $version = $1;
+ }
+ else {
+ tag 'unknown-copyright-format-uri', $original_uri;
+ }
+ if (defined $version) {
+ if ($version =~ m,wiki,) {
+ tag 'wiki-copyright-format-uri', $original_uri;
+ }
+ elsif ($version =~ m,svn$,) {
+ tag 'unversioned-copyright-format-uri', $original_uri;
+ }
+ elsif (versions_compare $version, '', $dep5_last_normative_change) {
+ tag 'out-of-date-copyright-format-uri', $original_uri;
+ }
+ if (versions_compare $version, '=', $dep5_last_overhaul) {
+ # We are reasonably certain that we're dealing with an up-to-date
+ # DEP-5 format. Let's try to do more strict checks.
+ eval {
+ @dep5 = read_dpkg_control($copyright_filename);
+ };
+ if ($@) {
+ $@ =~ s/^internal error: //;
+ tag
Bug#492493: When will su-to-root be available by default in Debian ?
Dear all, su-to-root is recommended by Lintian, but still not usable by default in Debian, causing confusion for users, and strange situations such as bug [1] and [2]. For memory, 2 alternative solutions were proposed in 2008's discussion [3] : - move su-to-root into debianutils where it would always be available, - or introducing an xdg-* utility into xdg-utils that does the same thing any update ? (I am developping graphical apps that need to be launched with admin privileges in live-session (whatever the DE), and because of this situation I think I will have to stick with gksu as dependency...) Best regards Yann [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492493 [2] https://bugs.launchpad.net/debian/+source/lintian/+bug/330533 [3] http://thread.gmane.org/gmane.linux.debian.devel.release/19273
Bug#492493: When will su-to-root be available by default in Debian ?
yannubu...@gmail.com yannubu...@gmail.com writes: For memory, 2 alternative solutions were proposed in 2008's discussion [3] : - move su-to-root into debianutils where it would always be available, - or introducing an xdg-* utility into xdg-utils that does the same thing any update ? The debianutils maintainer is not willing to include su-to-root. I haven't heard of any progress on the xdg-* front. (I am developping graphical apps that need to be launched with admin privileges in live-session (whatever the DE), and because of this situation I think I will have to stick with gksu as dependency...) Why don't you just depend on menu and use su-to-root? It would be friendlier for people who aren't using GNOME, and you're already having to depend on the package that provides the tool you want to use. -- 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/87fwl3jt65@windlord.stanford.edu
Bug#492493: When will su-to-root be available by default in Debian ?
Russ Allbery r...@debian.org writes: yannubu...@gmail.com yannubu...@gmail.com writes: For memory, 2 alternative solutions were proposed in 2008's discussion [3] : - move su-to-root into debianutils where it would always be available, - or introducing an xdg-* utility into xdg-utils that does the same thing any update ? The debianutils maintainer is not willing to include su-to-root. I haven't heard of any progress on the xdg-* front. Oh, sorry, I misremembered -- I don't recall the debianutils maintainer weighing in. I think that statement was about sensible-utils, not debianutils. I generally agree with the idea that something cross-distro would be better, and hence xdg-su would be the best solution, but if they're not willing to use anything other than PolicyKit, that seems like a showstopper there. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bovrjt1r@windlord.stanford.edu -- 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/87bovrjt1r@windlord.stanford.edu
