From owner-cvs-all Mon Dec 13 19: 4:20 1999 Delivered-To: cvs-all@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id A233714D16; Mon, 13 Dec 1999 19:04:13 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id TAA96144; Mon, 13 Dec 1999 19:03:47 -0800 (PST) (envelope-from dwhite@resnet.uoregon.edu) Date: Mon, 13 Dec 1999 19:03:47 -0800 (PST) From: Doug White To: Greg Lehey Cc: Andrzej Bialecki , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/release/picobsd Makefile src/release/picobsd/build Makefile Makefile.mfs In-Reply-To: <19991211113911.C355@mojave.sitaranetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Sat, 11 Dec 1999, Greg Lehey wrote: > > I appreciate your work, and I consider it to be a step in right direction, > > but you should've discussed this with either me or Doug White before > > committing ( *cough* the word MAINTAINER comes to my mind). > > Indeed. I looked for a Makefile, but I couldn't find one, so I sent a > message to FreeBSD-small asking what people thought. I thought of > sending you a message separately, but you're on FreeBSD-small, and you > hadn't shown any activity for over a year. You also didn't comment on > my suggestions there. I didn't know Doug White had anything to do > with PicoBSD, but if he does, I would have expected him to be on > -small. I'll take blame for not being on -small (along with the other 12 FreeBSD lists i'm on), but 'cvs log' exists for a reason. > > The end result for now is that we have two conflicting methods of > > building the floppies, and neither works (you broke the "custom" > > target when building with 'build' script, > > There was no custom target. There was too, I used it when making 'install'! :-) It was broke until I committed changes to use a ${PICOBSD_ROOT}-ish variable instead of depending on relative paths. > All the commits are additional files which don't touch the old build > method in anyway. I went to some trouble *not* to break the old build > method more than it was already broken. I don't believe it has worked > for at least 6 months, maybe a year. I haven't been able to build any > version, and the newest PicoBSD images I found date to September 1998. > One example for "don't break the old version" was that I would have > liked to remove files from the picobsd/floppy.tree hierarchy, but I > didn't; instead, I copied them to the image and then deleted them > again in the Makefile. That was what 'floppy.tree.exclude' was for. > > Well, not really. The individual floppies were there for a reason: smaller > > memory footprint. While it's becoming of less concern nowadays, there is > > still a lot of people with old junky 486 with 8MB SIMM RAM. A general > > purpose, one-size-fits-all floppy doesn't work for them. > > As I said, they won't build under -CURRENT. The kernel has got too > big. But I haven't changed anything in this area. They built no less than last November. I personally checked them since I was trying to hack them down to fit in low-memory environments. Just when did you take your PicoBSD snapshot, before or after early October, when I committed Luigi's mega-fix? > First, move to a Makefile-based build. This will enable automatic > builds, so people making changes will see when they break something. > At the moment, I can't compile ppp and something else (passwd?) which > I've forgotten. I like this. I think it started out Makefile-based and had to move to scripts to hack around the MFS loading limitations in 2.2.X. 3.X made it a module and better suited to Makefile-based builds. Luigi just shuffled the scripts around and I'm not very good at Makefiles. > Next, fix the old builds. I chickened out in the custom build and > just commented out the programs that didn't work. We need to go back > and fix those builds. Also, there are some programs, like tcpdump, > which I would like to include, but which don't build because of their > unusual source dependencies; if you know how to teach crunchgen to > build tcpdump, I'm sure many people would be happy. That could be hacked, probably. I'm getting pretty familiar with bending crunchgen to my will. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message