From owner-freebsd-hackers Fri Mar 26 4:41:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tuminfo2.informatik.tu-muenchen.de (tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by hub.freebsd.org (Postfix) with ESMTP id DD5E514E38 for ; Fri, 26 Mar 1999 04:40:22 -0800 (PST) (envelope-from langd@informatik.tu-muenchen.de) Received: from hpsystem14.informatik.tu-muenchen.de ([131.159.4.9] EHLO hpsystem14.informatik.tu-muenchen.de ident: root [port 3346]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <111260-227>; Fri, 26 Mar 1999 13:40:49 +0000 Received: from langd@localhost (fake: hprbg4.informatik.tu-muenchen.de) by hpsystem14.informatik.tu-muenchen.de id <12045-8139>; Fri, 26 Mar 1999 13:40:16 +0100 Message-ID: <19990326134015.C26520@informatik.tu-muenchen.de> Date: Fri, 26 Mar 1999 13:40:15 +0100 From: Daniel Lang To: freebsd-hackers@freebsd.org Subject: make release - a nightmare Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hiho, this is a long story, I'm afraid, but I think I identified some of the main problems, so maybe they can be fixed.. I thought I could easily use my CVS-repository, and some disk-space to set up a SNAP-'release' suitable to install other boxes with... so far so good. Unfortunately it didn't turn out to be that easy. One of my main problems was, that there are no real 'checkpoints' at some stages, where you can continue if an error aborted, the whole build. There is at least one, I realized, that you can use 'make rerelease' if the source/doc/ports-trees once are checked-out from the rep. Still a very time-consuming cvs update has to be done :-/, but that wouldn't be a real problem, if the build would work. I guess my environment is sort of uncommon, since I'm not USA_RESIDENT, and therefore don't want kerberos and other encryption-stuff installed. There are some variables, that can be set in /etc/make.conf (MAKE_KERBEROSIV, USA_RESIDENT), which have been set correncly (i.e. not setting MAKE_KERBEROSIV at all). Further, after checking the Makefile in /usr/src/release I set NOCRYPT and NOKERBEROS as well in this Makefile. But, the problem persited: After the chroot, the build process _always_ changes into the /chroot-dir/usr/src/kerberosIV directory and tries to build it. That would be ok, if it would work, but then it aborts with something like "Don't know how to make k_getpwuid.c", I didn't check why this was happending, maybe an error in the Makefile or a missing file.. I didn't want it to build kerberos at all. The _only_ way to do it, was to suspend the build-process right aber the src-tree was updated and remove the entire kerberosiv-directory. That worked so far. The next problem happened, as docproj should be built, as this uses some ports, that require distfiles, that have not been on my system. Unfortunately, my system is not connected permanently, so the build was aborted again. This is of course no bug, but it should be mentioned somewhere, that it is recommended, to have the required distfiles present. This was not the end of the story, while compiling ../src/usr.sbin/ppp/ (I guess for the boot-floppies), the make depend (mkdep) fails, because in ms_chap.c is included. The Makefile in .../src/usr.sbin/ppp checks if encryption is installed, but, either mkdep doesn't honor it, or the chroot-environment tells a different story. I moved around this obstacle by copying /usr/include/rpc/des.h to /chroot-dir/usr/include/des.h Then, finally after many hours the release was built. I bootet from the floppies and started the installation, which went fine so far. Except, that I could select a compat22 distribution, that should enable 2.2.* and 3.0 a.out compatibility, but was not built. Since on my 3.1-STABLE production system, a.out binaries can still be executed (as the libraries are still present), I guess this is something for the future, maybe taken from -current, I didn't check on the freshly installed machine, yet. That all doesn't sound so bad, but it took ages and dozen times of make, that all started somewhat from the beginning again... I guess the problems with encryption distributions (kerbersos/des) happen from not passing some environment-variables into the chroot-environment. Further some checkpoints, to complete an interrupted build, especially after the chroot would be nice, maybe its possible to add some extra targets, to continue, after certain .release.X - steps have been completed. Generally more documentation about 'make release' would be nice. Well I volunteer to set up a webpage with the experiences I made during my encounter, maybe it could be included into the handbook some time. Any contributions are very welcome, but don't expect it to be finished soon, since currently I'm sort of busy (as you are all, as well, I guess ;-)). I just send this to freebsd-hackers, since it seems to be most appropriate list. Please feel free to bounce it to freebsd-bugs and/or any other list, that may be suitable as well. Regards, Daniel -- IRCnet: Mr-Spock - Soon I will be free, then hungry. - RL: Daniel Lang * dl@leo.org * +49 89 8540017 * http://www.leo.org/~dl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message