] On 02-May-01 Jordan Hubbard wrote:
] > From: Terry Lambert <[EMAIL PROTECTED]>
] >> 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
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
