NetBSD Problem Report #38651

From kre@munnari.OZ.AU  Tue May 13 11:25:27 2008
Return-Path: <kre@munnari.OZ.AU>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 9AB4563B293
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 13 May 2008 11:25:27 +0000 (UTC)
Message-Id: <200805131124.m4DBO4hq007401@jade.coe.psu.ac.th>
Date: Tue, 13 May 2008 18:24:04 +0700 (ICT)
From: kre@munnari.OZ.AU
To: gnats-bugs@gnats.NetBSD.org
Subject: libkver won't install in pkg_comp any more
X-Send-Pr-Version: 3.95

>Number:         38651
>Category:       pkg
>Synopsis:       libkver won't install in pkg_comp any more
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    seb
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 13 11:30:00 +0000 2008
>Closed-Date:    
>Last-Modified:  Sat May 14 23:55:00 +0000 2022
>Originator:     Robert Elz
>Release:        NetBSD 3.99.15 (pkgsrc current today - or anytime in last month)
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 3.99.15 NetBSD 3.99.15 (GENERIC-1.696-20060125) #8: Wed Jan 25 04:59:39 ICT 2006 kre@jade.coe.psu.ac.th:/usr/obj/current/kernels/JADE_ASUS i386
Architecture: i386
Machine: i386
>Description:
	pkg_comp uses libkver to similate a particular version of
	NetBSD in its arena, so packages can be built that run on
	any (older) desired version of NetBSD.

	Or it should.

	For the past month or so, pkg_comp has been unable to install
	libkver - instead it installs a version of pkg_tools in the
	/libkver directory within the pkg_comp arena.

>How-To-Repeat:
	pkg_comp removeroot
	build a pkg_comp config file with NETBSD_RELEASE set
		(and an appropriate set of binary sets, though
		for present purposes, "appropriate" doesn't really
		matter).
	pkg_comp makeroot

	After that anything attempted with pkg_comp will complain about
	not being able to load /libkver/libkver.so (or something like
	that) - not surprising, as the llibrary never gets created
	(though the instructions to use it do)

>Fix:
	No idea.   I suspect something may be broken in the way that
	pkgsrc decides to update its pkg_tools, along with the way
	standalone packages modify PREFIX to get themselves installed
	outside the normal /usr/pkg tree.   libkver attempts to
	defeat that by explcictly saying not to check the pkgtools
	version, and just use whatever comes - but it looks as if that
	ability no longer exists).

	A fix for this is important, pkg_comp with libkver is the
	truly sane way to build packages and maintain /usr/pkg, nothing
	else comes remotely close.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->seb
Responsible-Changed-By: reed@NetBSD.org
Responsible-Changed-When: Tue, 20 May 2008 01:17:50 +0000
Responsible-Changed-Why:
Assign to maintainer.
(of libkver).


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: tech-pkg@NetBSD.org
Subject: Re: pkg/38651: libkver won't install in pkg_comp any more 
Date: Thu, 28 Aug 2008 18:52:27 +0700

 This is a multipart MIME message.

 --==_Exmh_-20162606360
 Content-Type: text/plain; charset=us-ascii

 Since nothing has happened with this PR since I sent it in mid May,
 and as the bug has meant I have been unable to build any packages
 since then (my last successful update was early April, for a while
 after that I had no time for package updates), I thought I really
 should go find a fix that would (at least) work for me, and which
 just might motivate someone who really knows what they are doing
 with this stuff (which is certainly not I) to find a proper fix.

 The "unable to build" in the previous paragraph is because I only
 build packages using pkg_comp and libkver these days, aside perhaps
 from he bulk build framework (which does way more than I need)
 it is the only rational way to build & update packages (without
 having a throw away system where what's actually installed is
 irrelevant - pkg_comp more or less provides that environment).

 I build with NetBSD 3.0 sets (libkver emulating NetBSD 3.0), so the
 binary packages I create will work on any of the NetBSD systems I
 care about (no longer running anything older).  I need libkver to
 make that happen, as my build system is a 4.0 (and a bit) system now.

 To recap the problem ... pkg_comp wants to install libkver.so into
 /libkver/lib so its position is known, and LD_PRELOAD (or something)
 can be set in the environment so all commands run get libkver.so linked
 into them (which then makes uname output claim the system version is 3.0,
 or however it is set).

 libkver supported that by providing a standalone-install: target that
 installed into that fixed location.  It used to do that by simply setting
 PREFIX to /libkver when building libkver for this standalone-install.

 Until sometime in April (or maybe very early May) this year, that worked
 fine - neither libkver nor pkg_comp have been changed (in any way) since
 well before then.   But something in pkgsrc evidently changed, and that
 method of doing an install into a very non-standard place stopped working.

 Instead, what happened was that pkginstall (pkg_add etc) got installed
 into /libkver/* (because NetBSD 3.0's pkgtools are too old for pkgsrc
 these days, and as /libkver was empty (non-existing) and PREFIX was
 set to that, there was no other possible version, so a new one was made
 and installed, after that, libkver just vanished somewhere (I never found
 where it went, I did a find in the pkg_comp sandbox, and there was no
 mention of it anywhere).   Still, LD_PRELOAD was set to use it, so every
 command after it should have been installed simply failed to run.

 I append a patch below that alters the way libkver does the standalone-install
 (I think it should make no material difference to a "noemal" install of
 libkver, though I'm not sure why anyone would ever want one of those).

 A couple of notes...

 I set PKGREVISION - for a NetBSD package (with the entr\ire source in
 pkgsrc) that's really silly, you'd normally expect the rev number to
 just get bumped, but I'll leave that for someone else.  libkver has been
 (aside from this) stable fo so long now it should probably be promoted
 to version 1.0 or something, rather than just 0.7 or 0.6.1 (or 0.6nb1).

 I have CHECK_FILES forced to "no" in the standalone-install case - that's
 because the PLIST doesn't anticipate the lib files being yanked out of
 ${PREFIX}/lib and installed elsewhere and complains - since this is
 (where it matters to me anyway) using pkg_comp, and pkg_comp always sets
 PKG_DEVELOPER=yes the check-files test is normally defaulted to yes, and
 building aborts when t fails.  The no setting doesn't eliminate all of the
 poblems with the PLIST not matching what gets installed, but it reduces what's
 left to noise (when built this way no binary package gets created, and
 what is installed is installed well enough to work correctly, so the
 problems don't matter - as long as it works, no-one really cares what
 is in the pkg_comp arena - pkg_deleting this standalone libkver would be
 fatal to pkg_comp - just like when it couldn't install, deleting it is
 done by removing, and recoreating, the entire sandbox).

 This is all truly ugly, but here is the patch that worked for me.
 Someone, please, do something to either pkgsrc, or libkver, so
 this setup goes back to working properly again....

 kre

 ps: when in the libkver/files/Makefile.inc you might alwo want to
 change the sequence of spaces in the LIBDIR assignment to tabs, the
 way they normally should be.



 --==_Exmh_-20162606360
 Content-Type: text/plain ; name="Patch"; charset=us-ascii
 Content-Description: Patch
 Content-Disposition: attachment; filename="PATCH"

 Index: Makefile
 ===================================================================
 RCS file: /cvsroot/NetBSD/pkgsrc/pkgtools/libkver/Makefile,v
 retrieving revision 1.28
 diff -u -r1.28 Makefile
 --- Makefile	12 Apr 2008 22:43:09 -0000	1.28
 +++ Makefile	28 Aug 2008 10:51:38 -0000
 @@ -4,6 +4,7 @@
  CATEGORIES=		pkgtools
  MASTER_SITES=		# empty
  DISTFILES=		# empty
 +PKGREVISION=		1

  MAINTAINER=	seb@NetBSD.org
  #HOMEPAGE=
 @@ -46,7 +47,14 @@

  LIBKVER_STANDALONE_PREFIX?=	/libkver
  standalone-install:
 -	${MAKE} ${MAKEFLAGS} PKG_DBDIR=${LIBKVER_STANDALONE_PREFIX:Q}/pkg \
 -	  PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install
 +	${MAKE} ${MAKEFLAGS}					  \
 +		STANDALONE_INSTALL=${LIBKVER_STANDALONE_PREFIX:Q} \
 +		install
 +
 +.if target(standalone-install)
 +CHECK_FILES=	no
 +pre-install:
 +	${MKDIR} ${STANDALONE_INSTALL}/lib
 +.endif

  .include "../../mk/bsd.pkg.mk"
 Index: files/Makefile.inc
 ===================================================================
 RCS file: /cvsroot/NetBSD/pkgsrc/pkgtools/libkver/files/Makefile.inc,v
 retrieving revision 1.4
 diff -u -r1.4 Makefile.inc
 --- files/Makefile.inc	13 Dec 2003 17:45:59 -0000	1.4
 +++ files/Makefile.inc	28 Aug 2008 10:45:40 -0000
 @@ -2,7 +2,11 @@

  .if defined(PREFIX)
  # build from pkgsrc
 +.if defined(STANDALONE_INSTALL)
 +LIBDIR=		${STANDALONE_INSTALL}/lib
 +.else
  LIBDIR=         ${PREFIX}/lib
 +.endif
  BINDIR=		${PREFIX}/sbin
  MANDIR=		${PREFIX}/man
  .else

 --==_Exmh_-20162606360--


State-Changed-From-To: open->closed
State-Changed-By: jmmv@NetBSD.org
State-Changed-When: Fri, 12 Mar 2010 13:58:12 +0000
State-Changed-Why:
Nothing has happened in this ticket for a long time and pkg_comp works for me now.


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sat, 13 Mar 2010 11:00:55 +0700

     Date:        Fri, 12 Mar 2010 13:58:13 +0000 (UTC)
     From:        jmmv@NetBSD.org
     Message-ID:  <20100312135813.0CA1763B11D@www.NetBSD.org>

   | Synopsis: libkver won't install in pkg_comp any more
   | 
   | State-Changed-From-To: open->closed
   | State-Changed-By: jmmv@NetBSD.org
   | State-Changed-When: Fri, 12 Mar 2010 13:58:12 +0000
   | State-Changed-Why:
   | Nothing has happened in this ticket for a long time and pkg_comp works for me now.

 Please re-open this PR, I assure you it *DOES NOT* work now.

 I just moved aside my own (modified versions of pkg_comp and libkver,
 checked out the most up to date versions from CVS (not that either of
 those packages has been updated in ages) and tried a

 	pkg_comp makeroot

 Aside with the problems caused by having a very old pkg_install in the
 sets installed in the pkg_comp sandbox (I use NetBSD 4.0 release sets)
 that seems to work, with "seems" being the operative word.

 Immediately after the makeroot completed ...

 jade# pkg_comp -ctest chroot
 PKG_COMP ==> Mounting sandboxed filesystems
 PKG_COMP ==> Entering sandbox `/local/pkg_comp/test'
 Cannot open "/libkver/lib/libkver.so"

 PKG_COMP ==> Unmounting sandboxed filesystems

 That's because pkg_comp is (attempting to) use the stanalone-install
 target that is part of libkver's Makefile (in pkgsrc), which you can
 see in ...

 # makeroot_libkver
 # 
 #   If NETBSD_RELEASE is set to a version string, installs libkver 
 #   inside the sandbox and configures it.
 # 
 makeroot_libkver()
 {    
     local prefix script statfile

     if [ "$NETBSD_RELEASE" != "no" ]; then
         _BUILD_TARGET="$BUILD_TARGET"
         BUILD_TARGET="standalone-install"
         pkg_build pkgtools/libkver 
         BUILD_TARGET="$_BUILD_TARGET"
         echo "LD_PRELOAD=${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so; export LD_PRELOAD" >> $DESTDIR/etc/shrc
         echo "setenv LD_PRELOAD ${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so" >> $DESTDIR/etc/csh.login
         echo "setenv LD_PRELOAD ${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so" >> $DESTDIR/etc/csh.cshrc
         ln -s "$NETBSD_RELEASE" $DESTDIR/libkver_osrelease
     fi
 } 

 But the "standalone-install" target in libkver has been broken since
 some infrastructure change in pkgsrc ages (as in years) ago - and what's
 more, I think pkgsrc is correct, what the libkver Makefile is trying to
 do is insane.   What's more it is unnecessary, there are much better ways
 to achieve what pkg_comp needs than this nonsense.

 kre

 ps: personally I no longer care all that much, I use a heavily modified
 version of pkg_comp.  If I thought there was any interest in updating the
 version in pkgsrc, I'd send updates, but none of the ones I have sent before
 generated any interest at all (not even a "this is no good because...")
 so I got bored with sending them except where there's a direct bug that
 needs fixing (gnats does have patches for this particular problem as
 patches in some PR or other - you should ignore the patch in this PR though,
 that was an attempt to make standalone-install work, and while that actually
 works, it isn't the right way to handle this problem).

 pps: the (it seems too common) habbit of closing PR's just because they
 are "too old" really needs to be obliterated - eitehr a bug is fixed, or it
 is not fixed, if it is fixed (which includes never really existed), the PR
 should be closed for that reason.  If it is not understood, and the submitter
 can't be contacted, then that PR can also be closed, but if the bug is
 understood, or the original submitter is still having the problem (and is
 around to say so) then any PR should be left open, essentially forever (even
 after the system in which the bug was detected is no longer supported, unless
 it can be shown that the bug is not present in any supported version).

State-Changed-From-To: closed->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 13 Mar 2010 22:28:01 +0000
State-Changed-Why:
"nothing has happened" is not a valid reason for closing PRs


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sat, 13 Mar 2010 22:35:04 +0000

 On Sat, Mar 13, 2010 at 05:20:05AM +0000, Robert Elz wrote:
  > ps: personally I no longer care all that much, I use a heavily
  > modified version of pkg_comp.  If I thought there was any interest
  > in updating the version in pkgsrc, I'd send updates, but none of
  > the ones I have sent before generated any interest at all (not even
  > a "this is no good because...")  so I got bored with sending them
  > except where there's a direct bug that needs fixing (gnats does
  > have patches for this particular problem as patches in some PR or
  > other - you should ignore the patch in this PR though, that was an
  > attempt to make standalone-install work, and while that actually
  > works, it isn't the right way to handle this problem).

 I see 34839, 38230, 38232, 42267, 42789, FWIW.

 I have no idea why all of this gets ignored, since you seem to be one
 of the main users of pkg_comp, but I've also been reluctant to stick
 my oar in.

 Maybe an interim solution would be to import a separate pkg_comp_kre?

  > pps: the (it seems too common) habbit of closing PR's just because
  > they are "too old" really needs to be obliterated - eitehr a bug is
  > fixed, or it is not fixed, if it is fixed (which includes never
  > really existed), the PR should be closed for that reason.  If it is
  > not understood, and the submitter can't be contacted, then that PR
  > can also be closed, but if the bug is understood, or the original
  > submitter is still having the problem (and is around to say so)
  > then any PR should be left open, essentially forever (even after
  > the system in which the bug was detected is no longer supported,
  > unless it can be shown that the bug is not present in any supported
  > version).

 Yes indeed.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sun, 14 Mar 2010 13:01:50 +0700

     Date:        Sat, 13 Mar 2010 22:40:05 +0000 (UTC)
     From:        David Holland <dholland-pbugs@NetBSD.org>
     Message-ID:  <20100313224005.0D15163B86C@www.NetBSD.org>

   |  I see 34839, 38230, 38232, 42267, 42789, FWIW.

 42267 isn't one of mine (though I commented on it) - there's also
 29700 (now closed, but not yet fixed) and 42788 (not a pkg_comp PR,
 but very much related, which contains the fix for 29700 - 42788 and
 42789 together contain the better fix for this PR (or my opinion
 of a better fix anyway).   There were also one or two older ones
 that did get incorporated.

   |  since you seem to be one of the main users of pkg_comp,

 I'm one of the more vocal users, but I suspect that it is used rather more
 than many may suspect, people just don't always mention it.  It really is
 a great way to build packages - especially for people for whom the bulk
 build framework is overkill.

   |  Maybe an interim solution would be to import a separate pkg_comp_kre?

 A pkg_comp2 perhaps - while I have quite a lot of mods - meaningful
 exit status from "pkg_comp build" so it can be used in scripts, better
 control of output (where it goes and how much is produced - from pkg_comp
 itself, and more - aside from those PRs) it isn't nearly enough for
 it to get my name associated with it, the vast bulk of what I use is
 the same as what is in the standard pkgsrc version.

 kre

 ps: thanks for re-opening this one - though it really would be nicer to
 see it closed again (and fixed...)

From: Stephen Borrill <sborrill@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Wed, 17 Jun 2015 09:43:13 +0100

 The following patch fixes this for me. Yes, it's not pretty and means 
 the man pages, etc. go into /libkver too, but for the purposes of 
 pkg_comp that's unimportant.

 --- pkgtools/libkver/Makefile	9 Oct 2014 14:06:49 -0000	1.36
 +++ pkgtools/libkver/Makefile	17 Jun 2015 08:41:38 -0000
 @@ -47,7 +47,9 @@

   LIBKVER_STANDALONE_PREFIX?=	/libkver
   standalone-install:
 -	${MAKE} ${MAKEFLAGS} PKG_DBDIR=${LIBKVER_STANDALONE_PREFIX:Q}/pkg \
 -	  PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install
 +	${MKDIR} ${DESTDIR}${LIBKVER_STANDALONE_PREFIX} && \
 +	    ${MKDIR} ${DESTDIR}${LIBKVER_STANDALONE_PREFIX}/lib
 +	${MAKE} ${MAKEFLAGS} \
 +	    STANDALONE_INSTALL=${LIBKVER_STANDALONE_PREFIX:Q} 
 PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install

   .include "../../mk/bsd.pkg.mk"


 -- 
 Stephen

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Thu, 18 Jun 2015 02:54:11 +0000

 On Wed, Jun 17, 2015 at 08:45:01AM +0000, Stephen Borrill wrote:
  >  The following patch fixes this for me. Yes, it's not pretty and means 
  >  the man pages, etc. go into /libkver too, but for the purposes of 
  >  pkg_comp that's unimportant.

 This seems like a reasonable approach to me. (for what that's worth,
 which isn't a great deal)

 -- 
 David A. Holland
 dholland@netbsd.org

From: "Stoned Elipot" <seb@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38651 CVS commit: pkgsrc/pkgtools/libkver/files
Date: Sun, 20 Mar 2016 19:15:33 +0000

 Module Name:	pkgsrc
 Committed By:	seb
 Date:		Sun Mar 20 19:15:33 UTC 2016

 Modified Files:
 	pkgsrc/pkgtools/libkver/files: Makefile.inc

 Log Message:
 whitespace fix PR pkg/38651


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.5 pkgsrc/pkgtools/libkver/files/Makefile.inc

 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: kre@NetBSD.org
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sat, 14 May 2022 21:00:09 +0000

 On Wed, Jun 17, 2015 at 08:45:01AM +0000, Stephen Borrill wrote:
  >  The following patch fixes this for me. Yes, it's not pretty and means 
  >  the man pages, etc. go into /libkver too, but for the purposes of 
  >  pkg_comp that's unimportant.
  >  
  >  --- pkgtools/libkver/Makefile	9 Oct 2014 14:06:49 -0000	1.36
  >  +++ pkgtools/libkver/Makefile	17 Jun 2015 08:41:38 -0000
  >  @@ -47,7 +47,9 @@
  >  
  >    LIBKVER_STANDALONE_PREFIX?=	/libkver
  >    standalone-install:
  >  -	${MAKE} ${MAKEFLAGS} PKG_DBDIR=${LIBKVER_STANDALONE_PREFIX:Q}/pkg \
  >  -	  PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install
  >  +	${MKDIR} ${DESTDIR}${LIBKVER_STANDALONE_PREFIX} && \
  >  +	    ${MKDIR} ${DESTDIR}${LIBKVER_STANDALONE_PREFIX}/lib
  >  +	${MAKE} ${MAKEFLAGS} \
  >  +	    STANDALONE_INSTALL=${LIBKVER_STANDALONE_PREFIX:Q} 
  >  PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install
  >  
  >    .include "../../mk/bsd.pkg.mk"

 This never got committed... not sure if it's still necessary. And,
 kre, none of your other pkg_comp fixes seem to have been either -- all
 but one of the PRs I cited earlier in the discussion here back in 2010
 are still open.

 I also notice that in the meantime jmmv did a big rewrite of pkg_comp,
 so maybe it's all irrelevant now? I don't know, and I don't habitually
 use pkg_comp so I'm not in a good position to make decisions.

 What's the best thing to do moving forward? It would be nice to sort
 this out properly since these are among the oldest open pkgsrc PRs at
 this point.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sun, 15 May 2022 06:52:50 +0700

     Date:        Sat, 14 May 2022 21:05:01 +0000 (UTC)
     From:        David Holland <dholland-pbugs@netbsd.org>
     Message-ID:  <20220514210501.3CA241A9239@mollari.NetBSD.org>

   |  What's the best thing to do moving forward?

 Probably just close any pkgsrc related PR of mine that still exists.
 I haven't been doing almost any pkg building for the past couple of
 years, nothing is likely to still be relevant.

 Once the new system I'm getting (mentioned in current-users recently
 in the context of graphics cards) arrives, and is working, I will be
 building packages again, and anything which is still an issue, can get
 a new PR at that time.

 kre

>Unformatted:

Home	PR Database Search