From owner-freebsd-current Wed May 2 17:11:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 9CB7337B422 for ; Wed, 2 May 2001 17:11:07 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id RAA09836 for ; Wed, 2 May 2001 17:11:04 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAq1aWet; Wed May 2 17:10:51 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA26306 for current@FreeBSD.org; Wed, 2 May 2001 17:11:50 -0700 (MST) From: Terry Lambert Message-Id: <200105030011.RAA26306@usr01.primenet.com> Subject: Re: PATCH: partial fix for broken "make release"... To: current@FreeBSD.org Date: Thu, 3 May 2001 00:11:40 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ] On 02-May-01 Jordan Hubbard wrote: ] > From: Terry Lambert ] >> The "make release" stuff is broken, at least in 4.3, and possibly ] >> before that. ] >> ] >> There are several obviously broken things: ] >> ] >> o The libssh stuff is not installed, and it is not built ] > ] > That would be a failure in make world, not make release. ] ] He probably doesn't have src-crypto or cvs-crypto in his cvsup file. ] *shrug* Works fine here and worked fine for the 4.3 release build. I have src-crypto and cvs-crypto; the _ONLY_ thing that breaks is the pam_ssh, when it goes to link against libssh, which is not a shared object, and is not an installed target as a result of "make release". A "make world" works perfectly fine, and builds everything, including the "pam_ssh", just fine. Examining the "/usr/obj" and the CHROOT version of "/usr/obj" indicates that the difference is that the libssh isn't built in the chroot case, and is referenced via a relative path, instead of being referenced from where it _is_ built. Copying _just_ those libraries allows the "pam_ssh" build to complete successfully, and nothing else uses them. ] >> o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not ] >> available from any of the listed mirros in the "ports" ] > ] > That would be a failure in the ports collection, not make release. ] ] Yes. Haven't seen this locally though, but I may have these files ] prefetched to /usr/docdistfiles on the local snap building machine. The main problem here is that none of the mirrors listed in the "ports" have them, and the FreeBSD FTP server is presently in limbo or pushing up daisies, depending on who you ask. Copying them into the local /usr/ports/distfiles works (as was alluded to in Bruce A. Mah's message), and is a better workaround than waiting for the failure and restarting things, but is a much less useful thing than correcting the "ports" for these things to point to mirrors that work... ] >> o If you set KERNCONF to a non-default value ("GENERIC" is ] >> the default value), then sysinstall can't find it to ] > ] > I'm not clear as to why you'd want to? GENERIC is the best kernel for ] > creating generally useable releases, but I imagine you have some other ] > reason for chosing a specific configuration for which I also expect ] > you're copying the config file into ${CHROOTDIR}/usr/src/sys/${ARCH}/conf ] > from somewhere else? I can't see how this change by itself makes what ] > appears to be the desired functionality a reality. ] ] You could use LOCAL_PATCHES to do it if your patch created a new config ] file. This would be appropriate if you were rolling an internal release ] using your own kernel config. In that case his patches make sense. Exactly what I'm doing: I'm _not_ rolling a boxed set of CDROMs, I'm rolling an internal release using my own kernel config, which I want to be installed by default as a result of an "upgrade" procedure, so that I can upgrade machines from a coaster after I've burnt it and verified that it passes acceptance testing. Actually, the "boxed set of CDROMs" thing is really hard to do entirely correctly, since the ports build process is so arcane, which seems to be because the ports themselves are not "DESTDIR" clean, so they have to be built serially. There's also the "tools" directory, which I guess is copied in magically, because some of the CDROM distribution is built on (bletch!) DOS, instead of being 100% FreeBSD hosted. To elaborate on Jordan's guess, I'm actually _replacing_ the entire /usr/src/sys directory (and using a LOCAL_SCRIPT to do the same to the /usr/src/sys directory in the CHROOT environment at the right time during the build process. If I were truly a grumpy guy, I'd insist that the cvs checkout of the kernel sources be capable of using a different repository and a different tag. My next challenge will be to get my personal packages to show up as options in sysinstall, and to make their installation default for a particular installation set name... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message