Re: Possible mass filing of bugs, take #2.1

[Steve Kowalik]

At  7:01 pm, Wednesday, August 21 2002, Anthony Towns mumbled:
> linda doesn't run cleanly over the entire archive -- it misbehaves on
> some packages (leaving /tmp/linda-* directories about), and just seems
> to hang on others. I haven't tracked down what's causing this. I don't
> believe it includes all the checks lintian does either, although in some
> cases that might be a win...
> 
Bugs, patches, or pointers at packages which make it misbehave are always
welcome.

-- 
   Steve
 goodbye, netsnaipe
 kick netsnipe
 oops
 Overfiend: That's 'netxnipe'
 StevenK: bwa ha, I had totally forgotten that! :)

Re: Possible mass filing of bugs, take #2.1

[Josip Rodin]

On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> We've _finally_ got lintian running over the archive again, and it looks like
> we'll have some chance of keeping it working. The URL is
> 
>   http://people.debian.org/~joy/
> 
> until lintian.debian.org gets updated to point at the right site.

As some may already have noticed, the above URL is no longer functional,
and http://lintian.debian.org/ is moderately up to date instead.

-- 
 2. That which causes joy or happiness.

Re: Possible mass filing of bugs, take #2.1

[Joey Hess]

Anthony Towns wrote:
> Things like libdb1 compliance, usage of nice(2), statistics for debhelper
> versus debstd usage, are all better collected by lintian.debian.org than
> by separate scripts.

I quite agree, and I would love to stop churning auric each morning
grepping the whole archive for the last two of those. If I could hook
into something that would run my program incrementally each time a
updated package entered the archive, and give it a lintian source lab to
examine, much cpu would be saved. If the people working on lintian.d.o
are interested in supporting this type of thing, please get in touch
with me.

-- 
see shy jo

Bug#157449: lintian: check for missing reference to he perl license terms (Was: Re: Possible mass filing of bugs, take #2.1)

[Gergely Nagy]

Package: lintian
Version: 1.20.17
Severity: wishlist
Tags: patch

> Rather than mass filing bugs, can you write a lintian check for it
> instead?

As promised, here is the check:

diff -u -urNad old/copyright-file new/copyright-file
--- old/copyright-file  2002-08-20 23:04:54.0 +0200
+++ new/copyright-file  2002-08-20 23:04:41.0 +0200
@@ -164,6 +164,11 @@
 print "W: $pkg $type: copyright-does-not-refer-to-common-license-file 
$1\n";
 }
 
+if (m,(under )?(the )?(same )?(terms )?as Perl itself,i &&
+!(m,usr/share/common-licenses/, || m,usr/share/doc/perl,)) {
+print "E: $pkg: $type: copyright-file-missing-pointer-to-perl-license\n";
+}
+
 exit 0;
 
 # ---
diff -u -urNad old/copyright-file.desc new/copyright-file.desc
--- old/copyright-file.desc 2002-08-20 23:04:54.0 +0200
+++ new/copyright-file.desc 2002-08-20 23:04:36.0 +0200
@@ -112,3 +112,10 @@
 Ref: policy 13.6
 Info: In the directory name /usr/share/common-licenses, licenses is spelt with 
  an `s', not with as licences with a `c'.
+
+Tag: copyright-file-missing-pointer-to-perl-license
+Type: error
+Ref: policy 13.6
+Info: If your package is released under the same terms as Perl itself,
+ it should either refer to the Artistic and GPL files in the
+ /usr/share/common/licenses directory, or to /usr/share/doc/perl/copyright.


Obviously, this is tuned for Perl modules released under the same
terms as Perl itself.

The check is tested outside of lintian, and appears to work
correctly. I hope it'll work in lintian too.

Re: Possible mass filing of bugs, take #2.1

[Gergely Nagy]

> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > 
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> > 
> 
> I think we have better things to be nitpicky about.  Besides, lintian tries to
> only enforce policy.

Spelling checks... But we had that argument already, interested
parties can check the bug logs.


pgpXmyamSAAic.pgp
Description: PGP signature

Re: Possible mass filing of bugs, take #2.1

[Gergely Nagy]

> On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote:
> > Some time ago, I assembled a list of packages which were arch: all,
> > yet used binary-arch to build the package, and another list of
> > packages whose debian/copyright did not have a pointer to the full
> > license.
> 
> Rather than mass filing bugs, can you write a lintian check for it
> instead?

Well, how about writing a lintian check AND reporting? There is no
guarantee that the maintainer will run lintian over the package, so
I'd like to notify them.

(No, I will not write a linda check, that is up to StevenK, if it is
not done yet. :)


pgpQAc1xupw8a.pgp
Description: PGP signature

Re: Possible mass filing of bugs, take #2.1

[Florian Weimer]

Anthony Towns  writes:

> Things like libdb1 compliance, usage of nice(2), statistics for debhelper
> versus debstd usage, are all better collected by lintian.debian.org than
> by separate scripts.

Input for a database of historical MD5 hashes of individual files
would be nice, too.


-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 09:33:39PM +0200, Wichert Akkerman wrote:
> Previously Sean 'Shaleh' Perry wrote:
> > If all goes well I have the month of September for lintian hacking.
> So how does lintian compare to linda these days? Will both be
> actively maintained and do the exact same thing?

linda doesn't run cleanly over the entire archive -- it misbehaves on
some packages (leaving /tmp/linda-* directories about), and just seems
to hang on others. I haven't tracked down what's causing this. I don't
believe it includes all the checks lintian does either, although in some
cases that might be a win...

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Re: Possible mass filing of bugs, take #2.1

[Wichert Akkerman]

Previously Sean 'Shaleh' Perry wrote:
> If all goes well I have the month of September for lintian hacking.

So how does lintian compare to linda these days? Will both be
actively maintained and do the exact same thing?

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.wiggy.net/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
> On 20-Aug-2002 Josip Rodin wrote:
> > On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> I think we have better things to be nitpicky about.  Besides, lintian tries to
> only enforce policy.

>From an archive management POV, that's probably not good enough:
we need a tool that can run automatic checks over *all* our archive,
whether it's stuff that's definitely wrong or only indicative, whether
it's for policy or just curiousity or whatever.

Things like libdb1 compliance, usage of nice(2), statistics for debhelper
versus debstd usage, are all better collected by lintian.debian.org than
by separate scripts. And we really need to be able to get those sorts
of things in an easy and automated fashion, trying to keep a handle on
the sheer scope of all the software in Debian is difficult, at best.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Re: Possible mass filing of bugs, take #2.1

[Sean 'Shaleh' Perry]

On 20-Aug-2002 Josip Rodin wrote:
> On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
>> >> Rather than mass filing bugs, can you write a lintian check for it
>> >> instead?
>> > 
>> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
>> > others reverted it >:)
>> 
>> I think we have better things to be nitpicky about.  Besides, lintian
>> tries to only enforce policy.
> 
> Yeah, well, speaking of better things, when can we expect you to integrate
> my lab code patches? I've initially sent them back in August 2001.
> 

I just mailed AJ about that.

If all goes well I have the month of September for lintian hacking.

Re: Possible mass filing of bugs, take #2.1

[Josip Rodin]

On Tue, Aug 20, 2002 at 10:23:29AM -0700, Sean 'Shaleh' Perry wrote:
> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> > 
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> 
> I think we have better things to be nitpicky about.  Besides, lintian
> tries to only enforce policy.

Yeah, well, speaking of better things, when can we expect you to integrate
my lab code patches? I've initially sent them back in August 2001.

-- 
 2. That which causes joy or happiness.

Re: Possible mass filing of bugs, take #2.1

[Sean 'Shaleh' Perry]

On 20-Aug-2002 Josip Rodin wrote:
> On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
>> Rather than mass filing bugs, can you write a lintian check for it
>> instead?
> 
> He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> others reverted it >:)
> 

I think we have better things to be nitpicky about.  Besides, lintian tries to
only enforce policy.

Re: Possible mass filing of bugs, take #2.1

[Josip Rodin]

On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> Rather than mass filing bugs, can you write a lintian check for it
> instead?

He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
others reverted it >:)

> We've _finally_ got lintian running over the archive again, and it looks like
> we'll have some chance of keeping it working. The URL is
> 
>   http://people.debian.org/~joy/
> 
> until lintian.debian.org gets updated to point at the right site.

Note that lintian.d.o at the current site will likely also be up to date in
about thirteen hours :)

-- 
 2. That which causes joy or happiness.

Re: Possible mass filing of bugs, take #2.1

[Anthony Towns]

On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote:
> Some time ago, I assembled a list of packages which were arch: all,
> yet used binary-arch to build the package, and another list of
> packages whose debian/copyright did not have a pointer to the full
> license.

Rather than mass filing bugs, can you write a lintian check for it
instead?

We've _finally_ got lintian running over the archive again, and it looks like
we'll have some chance of keeping it working. The URL is

http://people.debian.org/~joy/

until lintian.debian.org gets updated to point at the right site.

Having a lintian check helps ensure this won't happen again, and gives
QA folks a way of double checking your results and noticing stuff that's not
fixed more easily, too.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Possible mass filing of bugs, take #2.1

[Gergely Nagy]

Hi!

Some time ago, I assembled a list of packages which were arch: all,
yet used binary-arch to build the package, and another list of
packages whose debian/copyright did not have a pointer to the full
license.

Unfortunately, I wasn't able to file the bugs at that time, so I redid
the test now. Since there were no objections last time, and I already
filed reports about these kind of bugs, I will start filing tonight.

As always, the results weren't checked by hand, so there might be
false positives (but I highly doubt it). I did not check the BTS
either, since I'm writing this offline. If I happen to submit
duplicate bugs, feel free to merge it or close it right away.

So! Here is the list, categorised by the type of the bug:

debian/copyright problems
=
In the following packages, debian/copyright does not include a
verbatim copy of their copyright and distribution license, nor any
pointers to /usr/share/common-licenses/{Artistic,GPL} or
/usr/share/doc/perl/copyright.

Since including a verbatim copy of the _whole_ license (with the
exception that in case of the GPL and some other selected licenses,
for which a pointer is enough) is a must, I believe this is at least
an important bug.

So, the packages with this kind of problem:

appconfig-perl, chatbot-eliza, ciphersaber, crypt-ssleay, delimmatch
freedb-disc-cover, glade-perl, hns2, html-munger, libacme-poe-knee-perl
libalgorithm-diff-perl, libalias-perl, libapache-authnetldap-perl
libapache-authznetldap-perl, libapache-configfile-perl
libapache-dbilogconfig-perl, libapache-dbilogger-perl, libapache-dbi-perl
libapache-reload-perl, libapache-session-perl, libarchive-tar-perl
libauthen-pam-perl, libbit-vector-perl, libboulder-perl
libbusiness-onlinepayment-tclink-perl, libcache-cache-perl, libcgi-pm-perl
libclass-autouse-perl, libcompress-zlib-perl, libconfig-ini-perl
libconvert-asn1-perl, libconvert-ber-perl, libconvert-units-perl
libcrypt-cracklib-perl, libcrypt-smbhash-perl, libcurses-perl
libdata-compare-perl, libdata-showtable-perl, libdate-calc-perl, 
libdbd-mysql-perl
libdbd-pg-perl, libdbd-ram-perl, libdbd-sqlite-perl, libdbi-perl
libdevice-serialport-perl, libdigest-hmac-perl, libdigest-md2-perl
libdigest-md4-perl, libdigest-md5-perl, libdigest-perl, libdigest-sha1-perl
libemail-valid-perl, liberror-perl, libexpect-perl, libextutils-f77-perl
libfile-cache-perl, libfile-slurp-perl, libfilesys-diskfree-perl
libfile-tail-perl, libfilter-perl, libgd-gd2-perl, libgd-noxpm-perl, libgd-perl
libgnome-gnorba-perl, libhtml-embperl-perl, libhtml-format-perl
libhtml-parser-perl, libhtml-table-perl, libhttp-ghttp-perl, 
libi18n-charset-perl
libimage-info-perl, libio-socket-ssl-perl, libio-stty-perl, libipc-run-perl
libipc-sharelite-perl, libjcode-pm-perl, liblingua-ispell-perl
liblog-agent-logger-perl, liblog-agent-perl, liblog-agent-rotate-perl
libmail-bulkmail-perl, libmail-cclient-perl, libmail-pop3client-perl
libmailtools-perl, libmath-basecalc-perl, libmd5-perl, libnet-daemon-perl
libnet-dns-perl, libnet-finger-perl, libnet-google-perl, libnet-ipnetmember-perl
libnet-jabber-perl, libnet-ldap-perl, libnet-netmask-perl, libnet-perl
libnet-ph-perl, libnet-rawip-perl, libnet-scp-perl, libnetserver-generic-perl
libnet-server-perl, libnet-smtp-server-perl, libnet-snmp-perl, libnet-snpp-perl
libnet-ssh-perl, libnet-ssleay-perl, libnet-telnet-perl, libnet-tftp-perl
libnet-whois-perl, libnet-whois-raw-perl, libnews-newsrc-perl
libparse-syslog-perl, libplot-perl, libplrpc-perl
libpoe-component-client-dns-perl, libpoe-component-client-http-perl
libpoe-component-irc-perl, libpoe-component-jobqueue-perl, libpoe-perl
libprpc-perl, librtf-document-perl, libschedule-cron-perl, libset-intspan-perl
libset-object-perl, libstorable-perl, libstring-random-perl, libsys-cpuload-perl
libtangram-perl, libtemplate-perl, libterm-shell-perl, libtest-harness-perl
libtest-unit-perl, libtext-kakasi-perl, libtext-template-perl
libtime-modules-perl, libunicode-japanese-perl, libunicode-map8-perl
libunicode-map-perl, libunicode-maputf8-perl, libunicode-string-perl
libxml-csv-perl, libxml-dom-perl, libxml-dumper-perl, libxml-filter-xslt-perl
libxml-generator-perl, libxml-grove-perl, libxml-libxml-perl, 
libxml-libxslt-perl
libxml-parser-perl, libxml-sablot-perl, libxml-sax-machines-perl
libxml-sax-writer-perl, libxml-stream-perl, libxml-twig-perl, libxml-xerces-perl
libxtm-perl, mime-lite, net-hotline, pilot-link, soap-lite, timedate

binary-arch VS Arch: all

Some of the packages are fully Architecture: all, yet, they build the
.deb in the binary-arch target. Since policy states that

`binary-arch' builds the binary packages which are specific to
a particular architecture, and `binary-indep' builds those
which are not.

I consider this a policy violation, therefore a serious bug.
(Hint: one shouldn't follow the dh_make template blindly. A little
thought is always a good thing.)

And the list of packages who were caug