Re: pkg/40457: Diffs for various minor pkgsrc-2008Q4 fixes

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: obache%NetBSD.org@localhost
Subject: Re: pkg/40457: Diffs for various minor pkgsrc-2008Q4 fixes
Date: Wed, 28 Jan 2009 01:59:21 -0500

 On Sat, 24 Jan 2009 08:15:04 +0000 (UTC)
 "OBATA Akio" <obache%netbsd.org@localhost> wrote:
 
 >  What is the "db4 failed to build in some C++ code" ?
 >  It should be fixed instead.
 
 I can confirm this package built fine now, I assume that the issue had
 to do with paths from /etc/profile which were absolute instead of
 appending to $PATH, which also fixed a problem building cdrtools
 earlier.
 
 >  
 >  > NSPR required an older autoconf to build, and the Makefile already
 >  > was fixed to require said autoconf;  yet it still invoked the new
 >  > autoconf rather than the old one, which requires the version suffix.
 >  
 >  If "autoconf213" is in USE_TOOLS, "autoconf" shold be just a wrapper of 
 > "autoconf-2.13".
 >  You can confirm it by "ls ${WRKDIR}/.tools/bin/autoconf".
 >  If it is not a symbolic link to "autoconf-1.13", it is the real issue.
 
 I can confirm this now also works, it might also be related to
 previous /etc/profile setting absolute PATH.
 
 >  
 >  > I'm not sure of the proper variable or fix to use here, netbsd-5 was 
 > installed
 >  > with in-base xorg, and no X11 related options are in mk.conf.  It somehow
 >  > couldn't find the path to glut, which is part of base xorg.  This hack 
 > worked
 >  > for me yet is not a proper solution.
 >  
 >  It is not X11 related matter, just builtin v.s. pkgsrc.
 >  ${BUILDLINK_PREFIX.glut} should know the path to glut.
 
 I saw a post from you with a fix for this, thanks
 
 >  > The following failed to build only because the bootstrap SBCL couldn't
 >  > be downloaded, as it didn't yet exist on the maintainer's site.
 >  > This fix isn't a proper solution, but since my kernel was built with
 >  > COMPAT_4 support I forced it to use an SBCL built for 4.0 as bootstrap.
 >  > I now have a working SBCL for 5.0 which may be used to bootstrap for 5.0,
 >  > if the maintainer is interested.
 >  
 >  Not only COMPAT_4, but also shared libraries for NetBSD-4, isn't it?
 
 Possibly, upgrades from 2.0 and up were always done from source on this
 system.  There however are no special compat packages installed.
 Interestingly however, I see only one libc on the system when I check,
 which is 12.163, however the libraries you are refering to might be
 others than libc.
 
 I have a working a working netbsd-5 SBCL 1.0.16, I however didn't
 contact the pkgsrc SBCL maintainer yet about this problem for him to
 either accept to upload mine or to also build one against netbsd-5.
 
 >  
 >  > Interestingly bogofilter configure script complained that "a proper libdb"
 >  > couldn't be found.  Making it use db4 worked for me.
 >  
 >  > -CONFIGURE_ARGS+=         --with-database=db
 >  > +CONFIGURE_ARGS+=         --with-database=db4
 >  
 >  from "make configure-help":
 >    --with-database=ENGINE  choose database engine
 >                            {db|qdbm|sqlite3|tokyocabinet} [db]
 >  There is no option "db4".
 >  You should read ${WRKSRC}/config.log to find why failed on your environment.
 
 Well, this now also builds fine with db.  Go figure :)  I'd blame PATH
 again but I'm less certain about this one.
 
 >  > This was also part of a now-closed PR, but it seems it never was applied.
 >  > It adds options to mplayer so that it doesn't fail to build when it 
 > detects
 >  > the existence of these libraries: speex and lzo.  Interestingly, it also
 >  > fails to build if ncurses is installed, unless built with the ncurses 
 > option,
 >  > because of conflicts with in-base curses (it detects ncurses and attempts
 >  > to use it yet wrongly without the buildlink include).
 >  
 >  What is the "now-closed PR" ?
 >  If it was closed without fixed all, comment to the PR and reopen instead.
 
 It was part of an older PR even larger than this one with multiple packages, 
so a new PR would be best indeed, which I'll file for mplayer only.
 
 >  > Ghostscript fails to build when debugging is disabled, it appears to be
 >  > a ghostcript bug, at linking time it couldn't find some symbols only built
 >  > when debugging is enabled.  I thus simply re-enabled debugging which was
 >  > commented out, which made it build fine.
 >  
 >  What is the failure?
 >  I can't reproduce it.
 
 Well, me neither.
 
 >  > Requires the ncurses buildlink include if ncurses exist on the system
 >  > (and a dependency of another package also requireing hunspell installs
 >  > ncurses).
 >  > 
 >  > Index: textproc/hunspell/Makefile
 >  
 >  > +.include "../../devel/ncurses/buildlink3.mk"
 >  
 >  It should already be included from "options.mk".
 
 I can't reproduce the problem either when relying on options.mk alone.
 
 >  > Another case using an older autoconf requireing the version prefix.
 >  >
 >  > Index: www/firefox/Makefile.common
 >  
 >  > Yet another similar case but with older automake.
 >  >
 >  > Index: www/libwww/Makefile
 >  
 >  Same as above.
 
 Indeed;  we can ignore this.
 
 >  > Requires ncurses buildlink include or it fails to build if ncurses exists
 >  > (which generally installs via another dependency).
 >  
 >  > Index: x11/vte/Makefile
 >  
 >  > +.include "../../devel/ncurses/buildlink3.mk"
 >  
 >  I can't reproduce it.
 >  In configure, just check ncurses, curses, termcap, so should just include
 >  mk/termcap.buildlink3.mk.
 
 I also can't reproduce it anymore.
 
 
 So out of this mess-of-a-PR there were two applied fixes, rest can be
 ignored, except for mplayer for which I'll file a separate PR.  Thanks
 for your patience Akio, this PR can probably be closed once pullup
 requests are done... 
 
 -- 
 Matt