Bug#930679: Please add overridable tag for not using dh sequencer

2019-08-03 Thread Clint Adams
On Sat, Aug 03, 2019 at 07:36:23PM +0200, Mattia Rizzolo wrote: > Anyway, CCing d-haskell@ for input as well. I think it would be fine to switch to a resurrected-and-fixed or written-from-scratch replacement of dh-haskell, especially since cdbs seems to be bitrotting. Who's going to expend the

Bug#709365: lintian: check for standard license short names

2013-05-28 Thread Clint Adams
strings. From 1ca11e44e695ae45dcd222f20cbada0a3010661f Mon Sep 17 00:00:00 2001 From: Clint Adams cl...@softwarefreedom.org Date: Tue, 28 May 2013 11:24:44 -0400 Subject: [PATCH] Add checks and tests for short names containing spaces and short names that are probably meant to be standard values

Bug#709365: license strings

2013-05-28 Thread Clint Adams
For the historical record, I attach a sampling of license short names found in debian/copyright files claiming to be dep5 or copyright format 1.0. License: License: License: License: - License: 2-clause BSD License: 3BSD-like License: 3-clause BSD License: Academic License: Academic or LGPL-2+

Bug#709365: lintian: check for standard license short names

2013-05-23 Thread Clint Adams
On Thu, May 23, 2013 at 05:03:49PM +0200, Jakub Wilk wrote: So in some cases you _must_not_ use any of these standard names. What Lintian could do is to parse the full license text, see if it matches any standard license, and if it does then emit the tag. But that's far from trivial to

Bug#709365: lintian: check for standard license short names

2013-05-22 Thread Clint Adams
Mon Sep 17 00:00:00 2001 From: Clint Adams cl...@softwarefreedom.org Date: Wed, 22 May 2013 15:09:45 -0400 Subject: [PATCH] Add check and test for nonstandard short names. Currently lintian gives no feedback about choice of short name in debian/copyright, and this leads to use of strings like MIT

Bug#709365: lintian: check for standard license short names

2013-05-22 Thread Clint Adams
On Wed, May 22, 2013 at 10:08:54PM +0200, Niels Thykier wrote: Thanks for the idea and the effort in making a patch of it. However, I believe that specification allows anyone to invent a new ad-hoc license short name for any license without a standardised name: Yes, that's true, and

Bug#381800: lintian: [checks/scripts] unjustified possible-bashism-in-maintainer-script

2006-08-06 Thread Clint Adams
Currently, lintian reports the shell construct 'if [[ ... ]]' as bashism. I am not sure this is correct, since all POSIX 1003.2 resources available to me declare '[[' and ']]' a standard conditional expression check in POSIX sh (don't confuse with older Bourne sh). See, for example: They are

Bug#360534: canonical path for zsh

2006-04-02 Thread Clint Adams
Package: lintian Version: 1.23.16 /bin/zsh will probably outlive /usr/bin/zsh diff -ur lintian-1.23.16.old/checks/scripts lintian-1.23.16/checks/scripts --- lintian-1.23.16.old/checks/scripts 2006-03-25 12:02:09.0 -0500 +++ lintian-1.23.16/checks/scripts 2006-04-02

Bug#259109: wrong permissions on /usr/bin/lintian

2004-07-13 Thread Clint Adams
Yeah, I had a outdated build environment and seem to have been struck by a bug related to sed -i. Is it correct that this is bug #257232? How is sed -i being invoked? lintian SVN at svn.debian.org appears to be empty.

Bug#259109: wrong permissions on /usr/bin/lintian

2004-07-13 Thread Clint Adams
sed -i 's/VERSION/$(VER)/' $(tmp)/usr/bin/lintian Hmm. That's not the same bug. I think your sed build-dep is probably irrelevant.

Bug#259109: wrong permissions on /usr/bin/lintian

2004-07-13 Thread Clint Adams
Hmm. I can confirm now that the issue is indeed fixed in 4.1-4. I tested all versions since 4.1-1 with the attached test script and produces the following output: Hmm, okay.

Bug#259109: wrong permissions on /usr/bin/lintian

2004-07-12 Thread Clint Adams
Package: lintian Version: 1.23.1 Severity: grave % ls -l /usr/bin/lintian -rw-r--r--1 root root45462 2004-07-12 19:37 /usr/bin/lintian

Bug#253012: Bug#253498: non-posixisms

2004-06-18 Thread Clint Adams
+ '(test|\[) .+-[ao]', # test/[ -a/-o binary operators (test|\[).+\s-[ao]\s perhaps? (test|\[)\s+.+\s-[ao]\s might be less dangerous. This has still the problem of mathing stuff in but we can probably ignore that. You mean like bash -c test $blah -o $blah ? +

Bug#253621: [ef]grep check

2004-06-18 Thread Clint Adams
What is the rationale behind this? Could you please explain that further? Since nowadays egrep and fgrep are just shell scripts that run 'grep -E' or 'grep -F', running grep directly is always faster. Furthermore, I believe that some people are working on POSIXifying base for some embedded

Bug#253621: [ef]grep check

2004-06-10 Thread Clint Adams
Package: lintian Version: 1.23.0 lintian should check for use of fgrep or egrep in scripts and suggest the use grep -F or grep -E instead.

Bug#253498: lintian should check for cshisms in #!/bin/sh scripts

2004-06-09 Thread Clint Adams
Package: lintian Version: 1.23.0 lintian should complain about cshisms like redirection in /bin/sh scripts.

Bug#253498: non-posixisms

2004-06-09 Thread Clint Adams
tags 253012 + patch tags 253498 + patch quit These RE's could be tweaked, I imagine, but they're better than the current situation. --- /usr/share/lintian/checks/scripts 2004-04-25 17:53:59.0 -0400 +++ checks/scripts 2004-06-09 15:59:57.703351772 -0400 @@ -422,7 +422,15 @@

Bug#253012: check for common POSIX violations in /bin/sh scripts

2004-06-06 Thread Clint Adams
Package: lintian Version: 1.23.0 Severity: wishlist lintian should check /bin/sh scripts for matches to expressions similar to the following, and scream bloody murder if they're found. test .*-[ao]. command -v. kill -[0-9A-Z]