NetBSD Problem Report #46570

From dholland@netbsd.org  Sat Jun  9 20:46:00 2012
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id D974663B882
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  9 Jun 2012 20:45:59 +0000 (UTC)
Message-Id: <20120609204559.CA27C14A1D0@mail.netbsd.org>
Date: Sat,  9 Jun 2012 20:45:59 +0000 (UTC)
From: dholland@NetBSD.org
Reply-To: dholland@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: infelicities in pkglint
X-Send-Pr-Version: 3.95

>Number:         46570
>Category:       pkg
>Synopsis:       infelicities in pkglint
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 09 20:50:00 +0000 2012
>Closed-Date:    
>Last-Modified:  Sat Apr 12 12:50:01 +0000 2014
>Originator:     David A. Holland
>Release:        pkgsrc of 20120609
>Organization:
>Environment:
irrelevant
>Description:

pkglint has a number of regrettable characteristics.

- It is written in perl and is thus difficult at best to maintain,
especially now that the original author has left the project.

- It is also 8500 lines of perl in a single file, which is a problem
in its own right.

- It does not understand USE_GAMESGROUP or its accompanying
paraphernalia, and issues a bucket of spurious warnings instead of
guiding correct usage. I looked into fixing this at one point and was
stopped by the first two issues.

- It has a system of permissions for make variable usage in various
contexts, which is fine, but when it warns about violations it reports
the permissions as single letters. The letters are not documented in
the man page. To find out what they mean, you need to UTSL (see points
1 and 2) or notice the -e option. It should use words in the
diagnostics, especially since we encourage novice packagers to use
pkglint.

- It will happily attempt to check gmake makefiles (which can appear
in a package's files/ directly) ... and then when it encounters gmake
syntax, which it doesn't understand, it doesn't even spew errors but
*aborts*.

- If it encounters a file called Makefile.PL it expects it to be a
makefile (rather than a perl script) and *aborts* when it finds the
syntax confusing.

- It doesn't understand the .-include "file" syntax and *aborts* upon
encountering it in a makefile.

- Currently when run in ruby18-base it somehow imagines that it should
be looking at ruby19-base's patches and spews about six screenfuls of
completely nonsensical errors.

- It complains incorrectly about not being in -e mode if it encounters
a makefile recipe with a shell for loop, because of the semicolon in
the for loop syntax.

- It is slow. Running it on a significant portion of the tree takes
minutes (until it crashes out from one of the above issues) at 85-95%
CPU on a decently fast machine.

- There is quite a bit more wrong but the preceding is enough to start
with for now.

>How-To-Repeat:

Run it a lot.

>Fix:

A good start would be rewriting it not in perl.

>Release-Note:

>Audit-Trail:
From: diro@nixsyspaus.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Tue, 26 Jun 2012 15:51:35 -0400

 Agreed regarding rewriting it not in Perl. I've seen some inconsistencies in pkglint as well. Here are a few for now and i will trickle more in as i see them:

 1) It doesn't understand FETCH_USING:

 WARN: Makefile:7: FETCH_USING is defined but not used. Spelling mistake?

 2) It did not throw an error on this line:

 ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d

 Non-closed braces need to throw an error.

 3) This line needs to throw an error too:

 DEPENDS+=               itstool[0-9]*:../../textproc/itstool

 The lack of a dash between the package and version cause this dependency to
 not be detected if it's installed (it's seen as a different package). pkglint
 needs to tell the developer that dependencies must include a name and version.


 These are seen with pkglint-4.106. Not sure if they've been fixed yet.

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint/files
Date: Mon, 9 Jul 2012 17:36:59 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Mon Jul  9 17:36:59 UTC 2012

 Modified Files:
 	pkgsrc/pkgtools/pkglint/files: pkglint.1

 Log Message:
 Document permissions. Addresses part of PR 46570.


 To generate a diff of this commit:
 cvs rdiff -u -r1.43 -r1.44 pkgsrc/pkgtools/pkglint/files/pkglint.1

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 19:42:24 +0200

 I'll not comment further about the complaints about the language,
 because it is a well-written script in a language intended for
 handling text, and does it job well for single packages.

 On Sat, Jun 09, 2012 at 08:50:01PM +0000, David Holland wrote:
 > - It does not understand USE_GAMESGROUP or its accompanying
 > paraphernalia, and issues a bucket of spurious warnings instead of
 > guiding correct usage. I looked into fixing this at one point and was
 > stopped by the first two issues.

 I've just fixed these issues. USE_GAMESGROUP wasn't even documented in
 the guide, so I fixed that as welll.

 > - It has a system of permissions for make variable usage in various
 > contexts, which is fine, but when it warns about violations it reports
 > the permissions as single letters. The letters are not documented in
 > the man page. To find out what they mean, you need to UTSL (see points
 > 1 and 2) or notice the -e option. It should use words in the
 > diagnostics, especially since we encourage novice packagers to use
 > pkglint.

 I've added a reference to -e in the final output line if any problems
 were found, and documented the permissions in the man page.

 > - It will happily attempt to check gmake makefiles (which can appear
 > in a package's files/ directly) ... and then when it encounters gmake
 > syntax, which it doesn't understand, it doesn't even spew errors but
 > *aborts*.

 I don't see how this is a problem, since this is intended for checking
 pkgsrc Makefiles and only to be called from pkgsrc/category/program,
 where no GNU makefile should ever reside.

 > - If it encounters a file called Makefile.PL it expects it to be a
 > makefile (rather than a perl script) and *aborts* when it finds the
 > syntax confusing.

 I don't see how this is a problem, since this is intended for checking
 pkgsrc Makefiles and only to be called from pkgsrc/category/program,
 where no Perl Makefile.PL should ever reside.

 > - It doesn't understand the .-include "file" syntax and *aborts* upon
 > encountering it in a makefile.

 I don't see how this is a problem, since this is intended for checking
 pkgsrc Makefiles and only to be called from pkgsrc/category/program,
 where I didn't find any occurrence of ".-include" in the current
 pkgsrc tree, nor do I expect any to appear.ever reside.

 > - Currently when run in ruby18-base it somehow imagines that it should
 > be looking at ruby19-base's patches and spews about six screenfuls of
 > completely nonsensical errors.

 I can't reproduce this on ruby18-base nor ruby19-base, so I suspect
 this has been fixed in the meantime.

 > - It complains incorrectly about not being in -e mode if it encounters
 > a makefile recipe with a shell for loop, because of the semicolon in
 > the for loop syntax.

 Can you please give me an example package where I can reproduce this?

 Cheers,
  Thomas

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint/files
Date: Mon, 9 Jul 2012 17:47:37 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Mon Jul  9 17:47:37 UTC 2012

 Modified Files:
 	pkgsrc/pkgtools/pkglint/files: makevars.map

 Log Message:
 Recognize FETCH_USING as user-settable variable, as intended.
 Addresses a comment by diro in PR 46570.


 To generate a diff of this commit:
 cvs rdiff -u -r1.221 -r1.222 pkgsrc/pkgtools/pkglint/files/makevars.map

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint
Date: Mon, 9 Jul 2012 18:14:35 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Mon Jul  9 18:14:35 UTC 2012

 Modified Files:
 	pkgsrc/pkgtools/pkglint: Makefile
 	pkgsrc/pkgtools/pkglint/files: pkglint.pl

 Log Message:
 Allow "." in package names (needed e.g. for gst-plugins0.10-base).
 Check package patterns in DEPENDS.
 Requested by diro in PR 46570.
 Bump version.


 To generate a diff of this commit:
 cvs rdiff -u -r1.403 -r1.404 pkgsrc/pkgtools/pkglint/Makefile
 cvs rdiff -u -r1.834 -r1.835 pkgsrc/pkgtools/pkglint/files/pkglint.pl

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Mon, 09 Jul 2012 18:18:02 +0000
State-Changed-Why:
Waiting for example for shell loop issue.


Responsible-Changed-From-To: pkg-manager->wiz
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Mon, 09 Jul 2012 18:18:41 +0000
Responsible-Changed-Why:
Might as well take it.


From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: diro@nixsyspaus.org
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Mon, 9 Jul 2012 20:17:26 +0200

 >  1) It doesn't understand FETCH_USING:
 >  
 >  WARN: Makefile:7: FETCH_USING is defined but not used. Spelling mistake?

 I've added support for FETCH_USING to pkglint. (I've marked it as
 intended, i.e. currently with -Wall it will complain about packages
 that set it, since it shouldn't be used in package Makefiles; that's
 just a workaround until the infrastructure supports https better.
 Without -Wall pkglint won't complain about it.)

 >  2) It did not throw an error on this line:
 >  
 >  ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d
 >  
 >  Non-closed braces need to throw an error.

 It can't be a complete Makefile parser, and even make(1) doesn't complain about
 FOO= ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d

 I see this as WONTFIX.

 >  3) This line needs to throw an error too:
 >  
 >  DEPENDS+=               itstool[0-9]*:../../textproc/itstool
 >  
 >  The lack of a dash between the package and version cause this dependency to
 >  not be detected if it's installed (it's seen as a different package). pkglint
 >  needs to tell the developer that dependencies must include a name and version.

 I've added pattern checking for DEPENDS lines.
 It now complains about all of these cases:
 DEPENDS+=       broken0.12.1:../../x11/alacarte
 DEPENDS+=       broken[0-9]*:../../x11/alacarte
 DEPENDS+=       broken[0-9]*../../x11/alacarte
 DEPENDS+=       broken>=:../../x11/alacarte
 DEPENDS+=       broken=0:../../x11/alacarte
 DEPENDS+=       broken=:../../x11/alacarte
 DEPENDS+=       broken-:../../x11/alacarte
 DEPENDS+=       broken>:../../x11/alacarte

 Thanks for the suggestions!
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 20:32:25 +0000

 On Mon, Jul 09, 2012 at 05:45:02PM +0000, Thomas Klausner wrote:
  >  I'll not comment further about the complaints about the language,
  >  because it is a well-written script in a language intended for
  >  handling text, and does it job well for single packages.

 As long as there's someone maintaining it, I don't care what language
 it's written in. Heck, translate it to befunge or INTERCAL for all I
 care.

 However, if (as has been the case for some time before today)
 maintenance is left up to passersby and passersby are not able to
 successfully modify the thing, it constitutes a problem.

  >  > - It does not understand USE_GAMESGROUP or its accompanying
  >  > paraphernalia, and issues a bucket of spurious warnings instead of
  >  > guiding correct usage. I looked into fixing this at one point and was
  >  > stopped by the first two issues.
  >  
  >  I've just fixed these issues. USE_GAMESGROUP wasn't even documented in
  >  the guide, so I fixed that as welll.
  >  
  >  > - It has a system of permissions for make variable usage in various
  >  > contexts, which is fine, but when it warns about violations it reports
  >  > the permissions as single letters. The letters are not documented in
  >  > the man page. To find out what they mean, you need to UTSL (see points
  >  > 1 and 2) or notice the -e option. It should use words in the
  >  > diagnostics, especially since we encourage novice packagers to use
  >  > pkglint.
  >  
  >  I've added a reference to -e in the final output line if any problems
  >  were found, and documented the permissions in the man page.

 That's a start. How about having it output words? Then it wouldn't be
 necessary to look them up or explain them.

  >  > - It will happily attempt to check gmake makefiles (which can appear
  >  > in a package's files/ directly) ... and then when it encounters gmake
  >  > syntax, which it doesn't understand, it doesn't even spew errors but
  >  > *aborts*.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where no GNU makefile should ever reside.

 They can and do reside in files/, and when invoked with -Call as is
 usually recommended, pkglint takes it upon itself to inspect the
 contents of files/ and becomes confused. For example:

 % cd archivers/libarchive/
 % pkglint -Call
 FATAL: files/Makefile.am:175: Unknown line format: ./files/Makefile.am:175: if INC_WINDOWS_FILES
 Exit 1

  >  > - If it encounters a file called Makefile.PL it expects it to be a
  >  > makefile (rather than a perl script) and *aborts* when it finds the
  >  > syntax confusing.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where no Perl Makefile.PL should ever reside.

 They can and do reside in files/, and when invoked with -Call as is
 usually recommended, pkglint takes it upon itself to inspect the
 contents of files/ and becomes confused. For example:

 valkyrie% cd sysutils/p5-UPS-Nut/
 valkyrie% pkglint -Call
 WARN: ../../sysutils/ups-nut/Makefile.common:7: Please add a line "# used by sysutils/p5-UPS-Nut/Makefile" here.
 FATAL: files/Makefile.PL:4: Unknown line format: ./files/Makefile.PL:4: WriteMakefile(
 Exit 1

  >  > - It doesn't understand the .-include "file" syntax and *aborts* upon
  >  > encountering it in a makefile.
  >  
  >  I don't see how this is a problem, since this is intended for checking
  >  pkgsrc Makefiles and only to be called from pkgsrc/category/program,
  >  where I didn't find any occurrence of ".-include" in the current
  >  pkgsrc tree, nor do I expect any to appear.

 You didn't look in files/. Makefiles with this construction can and do
 reside in files/, and when invoked with -Call as is usually
 recommended, pkglint takes it upon itself to inspect the contents of
 files/ and becomes confused. For example:

 valkyrie% cd devel/bmake/
 valkyrie% pkglint -Call
 FATAL: files/Makefile.in:101: Unknown line format: ./files/Makefile.in:101: .-include <bsd.prog.mk>
 Exit 1

  >  > - Currently when run in ruby18-base it somehow imagines that it should
  >  > be looking at ruby19-base's patches and spews about six screenfuls of
  >  > completely nonsensical errors.
  >  
  >  I can't reproduce this on ruby18-base nor ruby19-base, so I suspect
  >  this has been fixed in the meantime.

 Yes, this has apparently been fixed. It was polluting the weekly check
 runs and therefore moderately visible.

  >  > - It complains incorrectly about not being in -e mode if it encounters
  >  > a makefile recipe with a shell for loop, because of the semicolon in
  >  > the for loop syntax.
  >  
  >  Can you please give me an example package where I can reproduce this?

 Not offhand, because I have been changing them when I find them.
 However, you don't need an existing example; just take your favorite
 test package and add this:

 post-install:
 	for x in foo bar baz; do \
 		${INSTALL_PROGRAM} "$$x" ${DESTDIR}${PREFIX}/share; \
 	done

 then run pkglint -Wall. You will get:

 WARN: Makefile:37--39: Please switch to "set -e" mode before using a semicolon to separate commands.

 On reflection the warning may be coming from the ; before "done"
 rather than the one before "do", but the shell won't accept && there
 so it's still wrong.


 And, btw, another one: pkglint bails out if it encounters a makefile
 line of the form "foo : bar", with a space before the colon. Arguably
 it's correct to object to this, but it shouldn't crash.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 22:41:11 +0200

 Where is it recommended to run pkglint -Call?
 I only know of the recommendations to run "pkglint -Wall".
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 20:44:38 +0000

 oops, I meant to reply to this part before sending:

 On Mon, Jul 09, 2012 at 08:35:02PM +0000, David Holland wrote:
  > >  > - It does not understand USE_GAMESGROUP or its accompanying
  > >  > paraphernalia, and issues a bucket of spurious warnings instead of
  > >  > guiding correct usage. I looked into fixing this at one point and was
  > >  > stopped by the first two issues.
  > >  
  > >  I've just fixed these issues.

 It is much better, but I still get e.g.

 WARN: Makefile:34: The user-defined variable GAMEMODE is used but not added to BUILD_DEFS.
 WARN: Makefile:37: Permission [s] requested for USE_GAMESGROUP, but only [u] is allowed.

 (these in maelstrom-x11)

  > >  USE_GAMESGROUP wasn't even documented in
  > >  the guide, so I fixed that as welll.

 I thought I did that ages ago, but maybe I only started and never
 finished, or something? Anyway, thanks.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 9 Jul 2012 23:58:53 +0200

 On Mon, Jul 09, 2012 at 08:45:04PM +0000, David Holland wrote:
 >  WARN: Makefile:34: The user-defined variable GAMEMODE is used but not added to BUILD_DEFS.
 >  WARN: Makefile:37: Permission [s] requested for USE_GAMESGROUP, but only [u] is allowed.
 >  
 >  (these in maelstrom-x11)

 Thanks, fixed.
  Thomas

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint
Date: Tue, 10 Jul 2012 09:39:27 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Tue Jul 10 09:39:27 UTC 2012

 Modified Files:
 	pkgsrc/pkgtools/pkglint: Makefile
 	pkgsrc/pkgtools/pkglint/files: pkglint.pl

 Log Message:
 Do not parse Makefiles in files/ or patches/
 Addresses another part of PR 46570 by David Holland.
 Bump version.


 To generate a diff of this commit:
 cvs rdiff -u -r1.405 -r1.406 pkgsrc/pkgtools/pkglint/Makefile
 cvs rdiff -u -r1.837 -r1.838 pkgsrc/pkgtools/pkglint/files/pkglint.pl

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint/files
Date: Tue, 10 Jul 2012 10:27:23 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Tue Jul 10 10:27:23 UTC 2012

 Modified Files:
 	pkgsrc/pkgtools/pkglint/files: pkglint.pl

 Log Message:
 Warn about space before colon in dependency line instead of FATALing out.
 Addresses part of PR 46570 by David Holland.


 To generate a diff of this commit:
 cvs rdiff -u -r1.838 -r1.839 pkgsrc/pkgtools/pkglint/files/pkglint.pl

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Tue, 10 Jul 2012 12:28:13 +0200

 On Mon, Jul 09, 2012 at 08:35:02PM +0000, David Holland wrote:
 >  That's a start. How about having it output words? Then it wouldn't be
 >  necessary to look them up or explain them.

 Done (not sure if I already mailed about that).

 >  They can and do reside in files/, and when invoked with -Call as is
 >  usually recommended, pkglint takes it upon itself to inspect the
 >  contents of files/ and becomes confused. For example:
 >  
 >  % cd archivers/libarchive/
 >  % pkglint -Call
 >  FATAL: files/Makefile.am:175: Unknown line format: ./files/Makefile.am:175: if INC_WINDOWS_FILES
 >  Exit 1
 >  
 >  They can and do reside in files/, and when invoked with -Call as is
 >  usually recommended, pkglint takes it upon itself to inspect the
 >  contents of files/ and becomes confused. For example:
 >  
 >  valkyrie% cd sysutils/p5-UPS-Nut/
 >  valkyrie% pkglint -Call
 >  WARN: ../../sysutils/ups-nut/Makefile.common:7: Please add a line "# used by sysutils/p5-UPS-Nut/Makefile" here.
 >  FATAL: files/Makefile.PL:4: Unknown line format: ./files/Makefile.PL:4: WriteMakefile(
 >  Exit 1
 >
 >  You didn't look in files/. Makefiles with this construction can and do
 >  reside in files/, and when invoked with -Call as is usually
 >  recommended, pkglint takes it upon itself to inspect the contents of
 >  files/ and becomes confused. For example:
 >  
 >  valkyrie% cd devel/bmake/
 >  valkyrie% pkglint -Call
 >  FATAL: files/Makefile.in:101: Unknown line format: ./files/Makefile.in:101: .-include <bsd.prog.mk>
 >  Exit 1

 Makefile* and *mk in files/ and patches/ aren't checked as Makefiles any longer.

 >  Not offhand, because I have been changing them when I find them.
 >  However, you don't need an existing example; just take your favorite
 >  test package and add this:
 >  
 >  post-install:
 >  	for x in foo bar baz; do \
 >  		${INSTALL_PROGRAM} "$$x" ${DESTDIR}${PREFIX}/share; \
 >  	done
 >  
 >  then run pkglint -Wall. You will get:
 >  
 >  WARN: Makefile:37--39: Please switch to "set -e" mode before using a semicolon to separate commands.
 >  
 >  On reflection the warning may be coming from the ; before "done"
 >  rather than the one before "do", but the shell won't accept && there
 >  so it's still wrong.

 Actually, I like the warning.

 I prefer this behavior:

 set -e; for i in 1 2 3; do  echo $i;  false;  done
 1
 *** Error code 1

 to:

 for i in 1 2 3; do  echo $i;  false;  done
 1
 2
 3
 *** Error code 1

 >  And, btw, another one: pkglint bails out if it encounters a makefile
 >  line of the form "foo : bar", with a space before the colon. Arguably
 >  it's correct to object to this, but it shouldn't crash.

 Fixed.

 I think I've addressed all your points. Anything else?
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Sat, 21 Jul 2012 23:53:09 +0000

 On Mon, Jul 09, 2012 at 06:20:04PM +0000, Thomas Klausner wrote:
  >>  2) It did not throw an error on this line:
  >>  
  >>  ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d
  >>  
  >>  Non-closed braces need to throw an error.
  >  
  >  It can't be a complete Makefile parser, and even make(1) doesn't
  >  complain about
  >  FOO= ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d
  >  
  >  I see this as WONTFIX.

 Well, it could be a complete makefile parser. But even if not, I think
 this is actually a moderately important thing to check for, if only
 because make *doesn't* always do it right and it's an easy typo to
 make.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 22 Jul 2012 01:59:54 +0000

 On Tue, Jul 10, 2012 at 10:30:12AM +0000, Thomas Klausner wrote:
  >>  Not offhand, because I have been changing them when I find them.
  >>  However, you don't need an existing example; just take your favorite
  >>  test package and add this:
  >>  
  >>  post-install:
  >>  	for x in foo bar baz; do \
  >>  		${INSTALL_PROGRAM} "$$x" ${DESTDIR}${PREFIX}/share; \
  >>  	done
  >>  
  >>  then run pkglint -Wall. You will get:
  >>  
  >>  WARN: Makefile:37--39: Please switch to "set -e" mode before using a semicolon to separate commands.
  >>  
  >>  On reflection the warning may be coming from the ; before "done"
  >>  rather than the one before "do", but the shell won't accept && there
  >>  so it's still wrong.
  >  
  >  Actually, I like the warning.
  >  
  >  I prefer this behavior:
  >  
  >  set -e; for i in 1 2 3; do  echo $i;  false;  done
  >  1
  >  *** Error code 1
  >  
  >  to:
  >  
  >  for i in 1 2 3; do  echo $i;  false;  done
  >  1
  >  2
  >  3
  >  *** Error code 1

 Sure. But you may just get

 set -e; for i in 1 2 3; do  echo $i;  false;  done
 1
 2
 3

 depending on what's actually written in place of the "false". This is
 the same sh standards issue that causes some packages' build systems
 to not stop on error.

 The safest way to do this, AFAICT, is

 for i in 1 2 3; do  echo $i; false || exit 1; done

 pkglint doesn't recognize this idiom.

  >  I think I've addressed all your points. Anything else?

 I'm currently getting a lot of these Perl messages:

 Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/pkglint line 4776.

 also, I'm getting the following internal errors from pkglint:

 ERROR: emulators/cygwin_lib/Makefile:30--33: Internal pkglint error: SCST_CONT: rest= $${f%.exe}); done
 ERROR: fonts/jisx0212fonts/Makefile:29--31: Internal pkglint error: SCST_CONT: rest=$${f%.*}; done
 ERROR: games/kanatest/Makefile:21: Internal pkglint error: SCST_CONT: rest= $${a%.po}.mo $$a; done
 ERROR: inputmethod/uim/options.mk:162: Internal pkglint error: SWST_PLAIN: rest=\.png
 ERROR: lang/gcc3-ada/buildlink3.mk:24: Internal pkglint error: SWST_PLAIN: rest=\buildlink:buildlink/gcc3:
 ERROR: lang/gcc34-ada/buildlink3.mk:25: Internal pkglint error: SWST_PLAIN: rest=\buildlink:buildlink/gcc34-ada:
 ERROR: lang/swi-prolog-packages/Makefile:61--62: Internal pkglint error: SCST_ECHO: rest= $$! >${WRKDIR}/.Xvfb.pid
 ERROR: mail/cyrus-imapd/Makefile:166--173: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/cyrus-imapd/Makefile:166--173: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/cyrus-imapd23/Makefile:116--123: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/cyrus-imapd23/Makefile:116--123: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/cyrus-imapd24/Makefile:115--122: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/cyrus-imapd24/Makefile:115--122: Internal pkglint error: SWST_PLAIN: rest=\.conf
 ERROR: mail/dk-milter/Makefile:51--53: Internal pkglint error: SWST_PLAIN: rest=\/
 ERROR: mail/sendmail/Makefile:90--91: Internal pkglint error: SWST_PLAIN: rest=\/
 ERROR: mail/sendmail/Makefile:93--95: Internal pkglint error: SWST_PLAIN: rest=\/
 ERROR: mail/thunderbird/Makefile:78--83: Internal pkglint error: SCST_CONT: rest= '/^    <em:id>/ {sub(".*
 ERROR: mail/thunderbird10/Makefile:74--79: Internal pkglint error: SCST_CONT: rest= '/^    <em:id>/ {sub(".*
 ERROR: pkgtools/pkg_install/Makefile:197--202: Internal pkglint error: SCST_CONT: rest=$${f%%.[157]}.cat; done
 ERROR: sysutils/syslog-ng/Makefile:86--88: Internal pkglint error: SWST_PLAIN: rest=\
 ERROR: www/horde/Makefile:121--123: Internal pkglint error: SCST_CONT: rest=$${f%.dist}; done
 ERROR: www/seamonkey/Makefile:64--69: Internal pkglint error: SCST_CONT: rest= '/^    <em:id>/ {sub(".*


 some other stuff from the pkglint -r run:

 ERROR: x11/gtk+extra/buildlink3.mk:5: Package name mismatch between GTK_EXTRA ...
 ERROR: x11/gtk+extra/buildlink3.mk:3: ... and gtk+extra.
 (this should be easy)

 ERROR: x11/py-wxWidgets/buildlink3.mk:5: Package name mismatch between PY_WXWIDGETS ...
 ERROR: x11/py-wxWidgets/buildlink3.mk:3: ... and ${PYPKGPREFIX}-wxWidgets.
 (I guess it'll need to know about PYPKGPREFIX and other multiversion prefixes)

 ERROR: print/teTeX3-bin/patches/patch-ab:69: This code must not be included in patches.
 (I have no idea what this warning is intended to mean or what's provoking it.)

 ERROR: lang/ruby/buildlink3.mk:14: There is no package in lang/${RUBY_BASE}.
 (is it too much to expect it to expand RUBY_BASE?)

 WARN: emulators/palmosemulator/Makefile:19: "${LP64PLATFORMS}" is not a valid platform triple.
 (it needs to know about this)

 WARN: security/ipsec-tools/Makefile:39: The user-defined variable VARBASE is used but not added to BUILD_DEFS.
 (surely VARBASE is in BUILD_DEFS by default?)

 WARN: graphics/gimp-fix-ca/Makefile:7: "&" is not a valid URL.
 WARN: graphics/gimp-fix-ca/Makefile:7: "id=9884" is not a valid URL.
 WARN: graphics/gimp-fix-ca/Makefile:7: "&" is not a valid URL.
 WARN: graphics/gimp-fix-ca/Makefile:7: "file=" is not a valid URL.
 (not clear why it's dicing up the url into substrings, but it's doing
 it wrong)

 WARN: lang/perl5/packlist.mk:76--81: "BEGIN { destdir = "${DESTDIR}"; gsub(/\/\//, "/", destdir); len_destdir = length(destdir); } { if (index($$1, destdir) == 1) $$1 = substr($$1, len_destdir + 1) }" is not a valid pathname.
 (why on earth does it expect this to be a pathname?)

 WARN: mail/mail-notification/Makefile:17: "./jb configure" is not a valid pathname.
 (it is, however, a valid thing to execute)

 WARN: net/uucp/Makefile:52: "/bin /usr/bin ${PREFIX}/bin" is not a valid pathname.
 (I guess it's latching onto these because the variable name contains "PATH"?)

 WARN: www/opera/Makefile:47: "x86_64" is not valid for EMUL_ARCH. Use one of { i386 none } instead.
 (guess it's out of date)

 WARN: archivers/unrar/Makefile:49: As .MAKEFLAGS is modified using "+=", its name should indicate plural.
 WARN: math/clisp-pari/Makefile:23: As ac_cv_libpari_libs is modified using "+=", its name should indicate plural.
 (but it does!)
 (this use of .MAKEFLAGS may be abusive, but that doesn't matter)

 WARN: shells/zsh/Makefile.common:92: CHECK_BUILTIN.curses is defined but not used. Spelling mistake?
 (pkglint should know about the CHECK_BUILTIN idiom)

 WARN: x11/gtk3/Makefile:66: Unknown compiler flag "-std=gnu99".
 WARN: audio/alsa-lib/Makefile:26: Unknown compiler flag "-std=c99".
 (surely it should know about these?)

 WARN: chat/pidgin-icb/Makefile:18: Compiler flag "`pkg-config pidgin --cflags`" does not start with a dash.
 WARN: chat/pidgin-icb/Makefile:19--20: Linker flag "`pkg-config pidgin --libs`" does not start with a dash.
 (and surely at this point it should be taught to recognize pkg-config)

 WARN: chat/p5-Net-Goofey/Makefile:19: "test" is not valid for INTERACTIVE_STAGE. Use one of { build configure extract fetch install } instead.
 (shouldn't this be legitimate?)

 WARN: mail/bulk_mailer/Makefile:17: Compiler flag "%s\"" does not start with a dash.
 (it's become confused by quoting)

 WARN: databases/py-cassa/Makefile:5: EGG_NAME is defined but not used. Spelling mistake?
 (why does it warn only here and not on every other Python module?)

 WARN: graphics/clutter/buildlink3.mk:17: Only buildlink variables for clutter, not MesaLib may be set in this file.
 (what it's doing is perfectly valid)

 WARN: graphics/libkipi-kde3/buildlink3.mk:8: Unknown dependency format: libkipi>=0.1.5<4.0
 (it appears to not understand all depends of this form)


 That's a bit more than I intended. Lots more where they came from though :-/

 and, btw, now at least I can do this without pkglint crashing, thanks.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 22 Jul 2012 02:04:19 +0000
State-Changed-Why:
New batch of issues submitted.

I've dropped the priority since it's no longer crashing out.


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Mon, 23 Jul 2012 06:17:19 +0000

 (sent to gnats instead of gnats-bugs)

    ------

 From: diro@nixsyspaus.org
 To: gnats@NetBSD.org
 Subject: Re: pkg/46570 (infelicities in pkglint)
 Date: Thu, 5 Jul 2012 16:38:02 -0400

 4) pkglint doesn't report an error on this line:

 LICENSE=        gnu-gpl-v2 gnu-lgpl-v2 modified-bsd mit

 Obviously, pkg_admin/bmake choke on the lack of ANDs/ORs in that line.


 5) pkglint needs to not complain about empty PLISTs for pear packages and
 other packages in which the PLIST is handled automagically.

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 30 Jul 2012 01:37:05 +0000

 On Sun, Jul 22, 2012 at 02:00:14AM +0000, David Holland wrote:
  > The following reply was made to PR pkg/46570; it has been noted by GNATS.
  >  I'm currently getting a lot of these Perl messages:
  >  
  >  Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/pkglint line 4776.

 This is caused by e.g. line 38 of x11/antiright/Makefile:

    TOOLS_DEPENDS.pkg-config=	pkg-config>=0.20:../../devel/pkg-config

 this line also generates

    WARN: Makefile:38: Permission [set] requested for TOOLS_DEPENDS.pkg-config, but only [] is allowed.

 which seems wrong.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Sun, 12 Aug 2012 20:25:43 +0200

 >  5) pkglint needs to not complain about empty PLISTs for pear packages and
 >  other packages in which the PLIST is handled automagically.

 It doesn't, AFAIK.
 # cd /usr/pkgsrc/www/pear-HTTP
 # pkglint 
 ERROR: Makefile: All packages must define their LICENSE.
 WARN: Makefile:6: "brook@nmsu.edu pkgsrc-users@NetBSD.org" is not a valid mail address.
 1 errors and 1 warnings found. (Use -e for more details.)
 # ls
 CVS      DESCR    Makefile distinfo
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 13 Aug 2012 19:56:23 +0000

 On Mon, Jul 09, 2012 at 08:45:02PM +0000, Thomas Klausner wrote:
  >  Where is it recommended to run pkglint -Call?
  >  I only know of the recommendations to run "pkglint -Wall".

 I don't know actually, I remember being told to use that to get it to
 print everything.

 However, it seems that it does appear in the guide:

 "Use e.g. pkglint -Call -Wall for a very thorough check."

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 26 Aug 2012 16:11:26 +0200

 On Mon, Jul 30, 2012 at 01:40:06AM +0000, David Holland wrote:
 >  On Sun, Jul 22, 2012 at 02:00:14AM +0000, David Holland wrote:
 >   > The following reply was made to PR pkg/46570; it has been noted by GNATS.
 >   >  I'm currently getting a lot of these Perl messages:
 >   >  
 >   >  Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/pkglint line 4776.
 >  
 >  This is caused by e.g. line 38 of x11/antiright/Makefile:
 >  
 >     TOOLS_DEPENDS.pkg-config=	pkg-config>=0.20:../../devel/pkg-config

 I've fixed the warning.

 >  this line also generates
 >  
 >     WARN: Makefile:38: Permission [set] requested for TOOLS_DEPENDS.pkg-config, but only [] is allowed.
 >  
 >  which seems wrong.

 It says that TOOLS_DEPENDS.pkg-config should not be changed by a
 package Makefile. Are you arguing that it should be allowed or that
 the error message should have some text between the brackets?
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 26 Aug 2012 20:54:54 +0000

 On Sun, Aug 26, 2012 at 02:15:04PM +0000, Thomas Klausner wrote:
  >>>  Use of uninitialized value in concatenation (.) or string at /usr/pkg/bin/pkglint line 4776.
  >>  
  >>  This is caused by e.g. line 38 of x11/antiright/Makefile:
  >>  
  >>     TOOLS_DEPENDS.pkg-config=	pkg-config>=0.20:../../devel/pkg-config
  >  
  >  I've fixed the warning.

 Thanks.

  >  >  this line also generates
  >  >  
  >  >     WARN: Makefile:38: Permission [set] requested for TOOLS_DEPENDS.pkg-config, but only [] is allowed.
  >  >  
  >  >  which seems wrong.
  >  
  >  It says that TOOLS_DEPENDS.pkg-config should not be changed by a
  >  package Makefile. Are you arguing that it should be allowed or that
  >  the error message should have some text between the brackets?

 Well, packages certainly need to be able to specify TOOLS_DEPENDS;
 that's practically the whole point of TOOLS_DEPENDS.

 Perhaps it should allow += but not =, though.

 I've noticed (I think) that sometimes pkglint will report that "only
 [] is allowed" but it actually accepts append, but I can't point to
 any examples.

 (It might also be better if it said "but no uses are allowed" instead
 of "only [] is allowed".)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 26 Aug 2012 23:11:23 +0200

 On Sun, Aug 26, 2012 at 08:55:03PM +0000, David Holland wrote:
 >   >  It says that TOOLS_DEPENDS.pkg-config should not be changed by a
 >   >  package Makefile. Are you arguing that it should be allowed or that
 >   >  the error message should have some text between the brackets?
 >  
 >  Well, packages certainly need to be able to specify TOOLS_DEPENDS;
 >  that's practically the whole point of TOOLS_DEPENDS.
 >  
 >  Perhaps it should allow += but not =, though.

 I guess you get the behaviour you want by changing pkgtools/files/makevars.map:
 TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$system]
 to
 TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$package_list]

 >  I've noticed (I think) that sometimes pkglint will report that "only
 >  [] is allowed" but it actually accepts append, but I can't point to
 >  any examples.

 That shouldn't happen any longer with 4.123. If the allowed flags were
 "au" which means append and use, then the warning was printing empty
 brackets.
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 27 Aug 2012 04:37:50 +0000

 On Sun, Aug 26, 2012 at 09:15:04PM +0000, Thomas Klausner wrote:
  >>  Well, packages certainly need to be able to specify TOOLS_DEPENDS;
  >>  that's practically the whole point of TOOLS_DEPENDS.
  >>  
  >>  Perhaps it should allow += but not =, though.
  >  
  > I guess you get the behaviour you want by changing
  > pkgtools/files/makevars.map:
  >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$system]
  >  to
  >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$package_list]

 Yes, that silences it. Should I commit?

  >  >  I've noticed (I think) that sometimes pkglint will report that "only
  >  >  [] is allowed" but it actually accepts append, but I can't point to
  >  >  any examples.
  >  
  >  That shouldn't happen any longer with 4.123. If the allowed flags were
  >  "au" which means append and use, then the warning was printing empty
  >  brackets.

 Good :-)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 27 Aug 2012 10:18:26 +0200

 On Mon, Aug 27, 2012 at 04:40:04AM +0000, David Holland wrote:
 >   > I guess you get the behaviour you want by changing
 >   > pkgtools/files/makevars.map:
 >   >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$system]
 >   >  to
 >   >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$package_list]
 >  
 >  Yes, that silences it. Should I commit?

 Yes, please. Bump version if you want, or not.
  Thomas

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Mon, 27 Aug 2012 14:07:04 +0000

 On Mon, Aug 27, 2012 at 08:20:05AM +0000, Thomas Klausner wrote:
  >  On Mon, Aug 27, 2012 at 04:40:04AM +0000, David Holland wrote:
  >  >   > I guess you get the behaviour you want by changing
  >  >   > pkgtools/files/makevars.map:
  >  >   >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$system]
  >  >   >  to
  >  >   >  TOOLS_DEPENDS.*         InternalList of DependencyWithPath [$package_list]
  >  >  
  >  >  Yes, that silences it. Should I commit?
  >  
  >  Yes, please. Bump version if you want, or not.

 I take it back: that silences it for += but also for =, which probably
 isn't desirable.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570 (infelicities in pkglint)
Date: Sun, 9 Sep 2012 20:56:13 +0000

 (two mails here, that were accidentally sent to gnats instead of gnats-bugs)

    ------

 From: diro@nixsyspaus.org
 To: gnats@NetBSD.org
 Subject: Re: pkg/46570 (infelicities in pkglint)
 Date: Wed, 5 Sep 2012 17:34:51 -0400

 Thanks, wiz, for the fixes. Just some more comments and infelicities:

 >> 2) It did not throw an error on this line:
 >>  
 >>  ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d
 > >  
 > >  Non-closed braces need to throw an error.

 > It can't be a complete Makefile parser, and even make(1) doesn't complain about
 > FOO= ${EGDIR/apparmor.d ${EGDIR/dbus-1/system.d ${EGDIR/pam.d
 >
 > I see this as WONTFIX.


 That seems reasonable. However, bmake _is_ a complete Makefile parser. Doesn't
 our make at least need to complain about this (I know it's not realistic to
 expect all the *make programs to fix this)?


 > I've just fixed these issues. USE_GAMESGROUP wasn't even documented in
 > the guide, so I fixed that as well.


 I would like to note that there are also many other things which are part of
 the pkgsrc framework that are not documented in the guide. It makes it more
 difficult for people like me, who jump in every few months, to track the changes
 in pkgsrc and to not resort to bothering #pkgsrc for answers if greping
 Makefiles in wip/ fails.

 Not meaning to turn this into a general complaint ticket about pkgsrc;
 however, since we've noticed that some things are not documented, could
 anything brought up in this thread, which is not documented already, be documented after discussion?

 >> 5) pkglint needs to not complain about empty PLISTs for pear packages and
 >>  other packages in which the PLIST is handled automagically.

 >It doesn't, AFAIK.
 > # cd /usr/pkgsrc/www/pear-HTTP
 > # pkglint 
 > ERROR: Makefile: All packages must define their LICENSE.
 > WARN: Makefile:6: "brook@nmsu.edu pkgsrc-users@NetBSD.org" is not a valid
 > mail address.
 > 1 errors and 1 warnings found. (Use -e for more details.)
 > # ls
 > CVS      DESCR    Makefile distinfo

 Ahh, but it does:

 # cd pkgsrc/wip/pear-HTTP_Client/
 # pkglint
 ERROR: ../../lang/php/pear.mk:69: Cannot read ./../../lang/php5/buildlink3.mk.
 WARN: PLIST:1: PLIST files shouldn't be empty.
 1 errors and 1 warnings found.

 Is is now preferred to not have any PLIST file for pear packages instead of
 an empty one?

 and:

 6) Like the previous behaviour with FETCH_USING (now fixed), it doesn't
 recognize RUN_LDCONFIG:

 WARN: Makefile:25: RUN_LDCONFIG is defined but not used. Spelling mistake?
 0 errors and 1 warnings found.


 From: diro@nixsyspaus.org
 To: gnats@NetBSD.org
 Subject: Re: pkg/46570 (infelicities in pkglint)
 Date: Fri, 7 Sep 2012 14:31:37 -0400

 7) pkglint doesn't understand KDE_LANGUAGE, even though it's defined in the
 various buildlink3.mk files that are connected to the package
 (x11/kde4-l10n-de, for example).

 # pkglint
 WARN: Makefile:3: KDE_LANGUAGE is defined but not used. Spelling mistake?
 0 errors and 1 warnings found.

 This may be getting too package specific, though, and not pkgsrc
 framework-specific.

From: diro@nixsyspaus.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570
Date: Thu, 27 Sep 2012 07:27:10 -0400

 8) pkglint needs to complain when packages have COMMENT set to "TODO: Short
 description of the package", a url2pkg default;


 Also, i recind my comment that pkglint not being a full Makefile parser is
 reasonable. It doesn't detect this:

 9) ${INSTALL_DATA} ${WRKSRC}/file.ext ${DESTDIR}${PREFIX}/wherever
    ${INSTALL_DATA) ${WRKSRC}/file2.ext ${DESTDIR}${PREFIX}/wherever2

 (See second INSTALL_DATA).

From: diro@nixsyspaus.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Sat, 10 Nov 2012 18:04:13 -0500

 10) BUILD_DEPENDS+= gtk2+>=2.16:../../x11/gtk2
 WARN: Makefile:36: Unknown dependency pattern "gtk2+>=2.16".

From: diro@nixsyspaus.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Tue, 13 Nov 2012 09:52:29 -0500

 11) pkglint needs to not completely implode on encountering empty options.mk
 (or other files):

 FATAL: Assertion failed: checklines_mk may only be called with non-empty
 lines..
   line 8498 called main::main
   line 8492 called main::checkitem
   line 8461 called main::checkdir_package
   line 8368 called main::checkfile
   line 7982 called main::checkfile_mk
   line 7089 called main::checklines_mk
   line 6048 called PkgLint::Util::assert

 More helpful would be a warning to the user that X file is empty and needs to
 not be.

From: diro@nixsyspaus.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Thu, 15 Nov 2012 19:10:58 -0500

 12) pkglint needs to complain if package options appear in both a
 PKG_OPTIONS_GROUP and in PKG_SUPPORTED_OPTIONS. This is harmless, but it
 causes the package options which appear in both to be shown twice after the
 depends stage.

Responsible-Changed-From-To: wiz->pkg-manager
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sat, 29 Dec 2012 12:28:00 +0000
Responsible-Changed-Why:
Realistically, I'm not going to fix all of these, so open this up
for others as well.


From: diro@nixsyspaus.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Wed, 2 Jan 2013 23:02:15 -0500

 13) Not sure if this would cause any problems, but if it doesn't... it would
 be nice to have pkglint error out when PKG_OPTIONS.$PKG != $PKGBASE in
 options.mk. 

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Sat, 19 Jan 2013 20:29:10 +0000

 14) pkglint demands that meta-packages have a LICENSE, even though
 this is silly.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Alan Barrett <apb@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570
Date: Sat, 19 Jan 2013 22:41:34 +0200

 15) If a package Makefile sets OWNER= then pkglint could complain
      about edits made by somebody other than the OWNER.  Edits could be
      detected by running "cvs diff" or some such, and the current user
      name could be found using the mechanism used by "make
      changes-entry".

      Similarly for MAINTAINER instead of OWNER, but the warning could be
      less severe.

From: "Amitai Schlair" <schmonz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46570 CVS commit: pkgsrc/pkgtools/pkglint
Date: Sat, 19 Jan 2013 22:51:12 +0000

 Module Name:	pkgsrc
 Committed By:	schmonz
 Date:		Sat Jan 19 22:51:12 UTC 2013

 Modified Files:
 	pkgsrc/pkgtools/pkglint: Makefile
 	pkgsrc/pkgtools/pkglint/files: pkglint.pl
 Added Files:
 	pkgsrc/pkgtools/pkglint/files: pkglint.t

 Log Message:
 Make it possible to easily write automated tests:

 * minimally adapt pkglint(1) into a "modulino" for testability
 * verify it still runs normally as a program
 * create a test script with a few very simple test cases
 * hook it up to 'make test'
 * verify that the tests really fail if I go breaking the code under test

 Meta-addresses PR pkg/46570. New BUILD_DEPENDS, but no functional
 change, so no PKGREVISION bump. Approved by wiz@.


 To generate a diff of this commit:
 cvs rdiff -u -r1.423 -r1.424 pkgsrc/pkgtools/pkglint/Makefile
 cvs rdiff -u -r1.847 -r1.848 pkgsrc/pkgtools/pkglint/files/pkglint.pl
 cvs rdiff -u -r0 -r1.1 pkgsrc/pkgtools/pkglint/files/pkglint.t

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 20 Jan 2013 19:39:17 +0000

 #16:

    ------

 From: OBATA Akio <obache@netbsd.org>
 To: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
 	yamajun@ofug.net
 Cc: 
 Subject: Re: pkg/47468: Update request: inputmethod/uim, inputmethod/uim-elisp
 	update to uim-1.8.4
 Date: Sat, 19 Jan 2013 08:15:05 +0000 (UTC)

 The following reply was made to PR pkg/47468; it has been noted by GNATS.

 From: "OBATA Akio" <obache@netbsd.org>
 To: gnats-bugs@netbsd.org
 Cc: 
 Subject: Re: pkg/47468: Update request: inputmethod/uim, inputmethod/uim-elisp
  update to uim-1.8.4
 Date: Sat, 19 Jan 2013 17:13:04 +0900

  On Sat, 19 Jan 2013 14:45:00 +0900, <yamajun@ofug.net> wrote:

  > pkgsrc changelog:
  > * Change value of CHECK_FILES_SKIP for pkglint(1)

  It's a false detection, should not be changed.
  As noted in mk/check/check-files.mk, it's a list of regular expression,
  not shell patterns.

  -- 
  OBATA Akio / obache@NetBSD.org

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>,
	OBATA Akio <obache@NetBSD.org>
Cc: 
Subject: Re: pkg/46570: infelicities in pkglint
Date: Sun, 20 Jan 2013 21:39:36 +0100

 On Sun, Jan 20, 2013 at 07:40:05PM +0000, David Holland wrote:
 >  #16:
 >  
 >  From: "OBATA Akio" <obache@netbsd.org>
 >  To: gnats-bugs@netbsd.org
 >  Cc: 
 >  Subject: Re: pkg/47468: Update request: inputmethod/uim, inputmethod/uim-elisp
 >   update to uim-1.8.4
 >  Date: Sat, 19 Jan 2013 17:13:04 +0900
 >  
 >   On Sat, 19 Jan 2013 14:45:00 +0900, <yamajun@ofug.net> wrote:
 >   
 >   > pkgsrc changelog:
 >   > * Change value of CHECK_FILES_SKIP for pkglint(1)
 >   
 >   It's a false detection, should not be changed.
 >   As noted in mk/check/check-files.mk, it's a list of regular expression,
 >   not shell patterns.

 These are the easiest to fix -- just modify the type in pkgtools/pkglint/files/makevars.map.

 I don't think there's a special regex-type, so "List of Unchecked [m:a,c:a]" is probably best.
  Thomas

From: rodent@NetBSD.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Wed, 27 Mar 2013 07:05:09 -0400

 17)
 > WARN: audio/festvox-tll/Makefile:12: License no-commercial-use is deprecated.
 > WARN: audio/festvox-us1/Makefile:12: License file licenses/no-commercial-use does not exist.

 Well, that's not very helpful. What is the new license then? Deprecations need
 always specify the new convention.

 18)

 > WARN: inputmethod/ibus-hangul/PLIST:6: Packages that install a .desktop entry should .include "../../sysutils/desktop-file-utils/desktopdb.mk".

 As obache@ pointed out in private mail, this needs to happen only if the
 MimeType key exists in the .desktop entry. pkglint needs to tell users to
 ignore this warning if this the file doesn't contain such a key.

 19) References #10:

 > WARN: x11/fltk/buildlink3.mk:8: Unknown dependency format: fltk>=1.1.5rc1<1.3

From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/46570
Date: Wed, 27 Mar 2013 13:37:50 +0100

 On Wed, Mar 27, 2013 at 11:10:07AM +0000, rodent@NetBSD.org wrote:
 >  17)
 >  > WARN: audio/festvox-tll/Makefile:12: License no-commercial-use is deprecated.
 >  > WARN: audio/festvox-us1/Makefile:12: License file licenses/no-commercial-use does not exist.
 >  
 >  Well, that's not very helpful. What is the new license then? Deprecations need
 >  always specify the new convention.

 There never was a license called "no-commercial-use". It was just a
 category used before we had proper license handling. There is no
 default that could be suggested here, it really depends on the
 package. IMO nothing that pkglint can do better in this case.
  Thomas

From: rodent@NetBSD.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Fri, 17 May 2013 21:47:27 -0400

 20) % cd pkgsrc/textproc/saxon; pkglint
 WARN: Makefile:3: The package is being downgraded from 9.4.0.7j to 1J.
 0 errors and 1 warnings found. (Use -e for more details.)
 % bmake show-var VARNAME=PKGNAME
 saxon-9.5.0.1j
 % bmake show-var VARNAME=PKGVERSION
 9.5.0.1j

From: rodent@NetBSD.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46570
Date: Sat, 12 Apr 2014 08:46:19 -0400

 No, we haven't forgotten about this one. ;) Another complaint:

 21) pkglint doesn't grok regex in PKGNAME:

 rodent@sammy:~/dev/www/sqtop% pkglint
 WARN: Makefile:4: "${DISTNAME:C/([0-9]{4})-([0-9]{2})-([0-9]{2})/\1\2\3/1}" is
 not a valid package name. A valid package name has the form
 packagename-version, where version consists only of digits, letters and dots.
 0 errors and 1 warnings found. (Use -e for more details.)
 rodent@sammy:~/dev/www/sqtop% bmake show-var VARNAME=PKGNAME
 sqtop-20131217

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.