Re: supfile idea (was Re: Releases)
At 10:04 PM 4/9/01 -0400, Matthew Emmerton wrote: >I like the idea of stable-supfile, so it should stay. standard-supfile >should *definitely* refer to the -REL in which it is a part of. In that >case, a novice user who doesn't change anything would end up cvsup'ing code >that they already have on their system or on CD - no harm done. Further, >they'd actually have to RTFM to figure out what tags to use to get what they >really want. Another issue that is common here and wonder if you are aware of this file: /usr/src/share/examples/cvsup/README Frankly I think there should be the readme and *ONE* example. There is a lot of duplication and since most use only one cvsupfile, possibly less confusion. I see there is a disclaimer for adding the ports collection in the "standard" version. Use that as a base and these: ports-supfile stable-supfile standard-supfile www-supfile Can be rolled into one, call it "new-supfile" for now, and now there are only: README cvs-supfile gnats-supfile new-supfile refuse refuse.README Less choices and changing "new" to "standard" should make it the obvious choice and not require building up a typical supfile. Not sure that the gnats could be folded in, as it uses "release=current" rather than "release=cvs" and does not use a "tag=" and having one might throw it off (John? anyone?). Also might not be a good idea to fold it in, since only those that work on PR's might want a local copy. Another common issue is when using individual collection vs src-all. Many time a person has src-crypto and no src-secure. Or worse, someone points out only one of them is missing and neglects to mention the other. It would be difficult to say what is optional, but if you consider /etc/defaults/make.conf *and* lose the comments before the crypto collections (outdated, but might be necessary in the future) then something like: # required by default #src-base #src-bin #src-contrib #src-etc #src-games #src-gnu #src-include #src-lib #src-libexec #src-sbin #src-share #src-sys #src-usrbin #src-usrsbin #src-crypto #src-secure #src-sys-crypto # optional #src-kerberos5 #src-kerberosIV #src-release #src-tools #src-eBones And perhaps a quick reference to make.conf and a suggestion to pull in src-release even if one doesn't wish to roll their own for the text files that everyone tracking stable *should* know about. Perhaps a quick reference to the handbook or FAQ to avoid cluttering the file like this. # comment the following if "NOGAMES=yes" in make.conf #src-games # un-comment the following if "MAKE_KERBEROS5=yes" in make.conf etc... The idea is to make it simple, central, and with simple comments that should avoid the common mistakes. And yes, I am aware that removing the supfiles for ports, doc, www, and stable would require a change to make.conf. They could remain and the standard might be updated to an all-in-one supfile rather than for -current. Perhaps all that is needed is a comment in the README to refer to the handbook for those new to fetching the source and what should be used when using individual collections. Minimal clutter and hopefully get more to RTFM before diving in. Mind right now I'm not sure where the docs are and how satisfactory they are (no insult to the docs people). Was going to update them, but find the docproj has bloated quite a bit in recent history. Might want to warn those fetching doc-all what it will take to build that beast. 8-) Can Kris or someone else say if src-sys-crypto is required or not. There was a discussion on this a long time back, but recall the answer was fuzzy and it *might* be required in the future for in-kernel crypto. I do list it when suggesting a trimmed down list rather than src-all. It's small and safer to do so. Rather than reply to another will agree with Donn that "standard" should be "current" to avoid confusion. Then making "standard" an all inclusive (or should I say "mostly") example might be a good idea along with pointing to documentation. Of course getting users to read things is always an issue. All the documentation in the world won't stop a (l)user from getting a bad case of LLMF. My question at this point is before changing a thing it would be best to find out how most get lost and then work out a remedy, which I could have stated in the first place and had less fun trying to cover a number of possibilities. It would be nice to force a new user to a certain minimum of RTFM, but might leave some cold and certainly won't stop them from not doing so, screwing up, and asking "why?" Attaching a copy of my idea of what standard-supfile should be like. standard-supfile-new Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve
4.3 release schedule still on track for April 15? (for Jordan)
Jordan, Is the 4.3 release date still on track for April 15, per your revised schedule as posted March 22 to this list? I'm planning a server maintenance window for later this month, and if possible I'd like to get some production boxes to 4.3-STABLE at the same time. Kill two or more birds. Thanks, -- Christopher Schulte Finger for PGP key, or for UNIX impaired: http://noc.schulte.org/cgi-bin/noc/finger.cgi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
4.3-RC2: broken crypto/CHECKSUM.MD5
IIRC, I've sent a email before about this, but nobody doesn't pay attention nor fix src/release/Makefile... In our all distribution, including 4.3-RC2, have incorrect CHECKSUM.MD5 file in crypto/ distribution. Here is the current distribution: % ls 4.3-RC2 RELNOTES.TXTcompat1xdictports ABOUT.TXT TROUBLE.TXT compat20doc proflibs ERRATA.TXT UPGRADE.TXT compat21floppiessrc HARDWARE.TXTXF86336 compat22games tools INSTALL.TXT bin compat3xinfo LAYOUT.TXT catpagescompat4xmanpages README.TXT cdrom.inf crypto packages % cd crypto % ls CHECKSUM.MD5crypto.inf krb5.ad scrypto.aj scrypto.aw crypto.aa crypto.mtreekrb5.ae scrypto.ak scrypto.ax crypto.ab install.sh krb5.infscrypto.al scrypto.inf crypto.ac krb4.aa krb5.mtree scrypto.am skrb4.aa crypto.ad krb4.ab scrypto.aa scrypto.an skrb4.inf crypto.ae krb4.ac scrypto.ab scrypto.ao skrb5.aa crypto.af krb4.ad scrypto.ac scrypto.ap skrb5.inf crypto.ag krb4.ae scrypto.ad scrypto.aq ssecure.aa crypto.ah krb4.infscrypto.ae scrypto.ar ssecure.inf crypto.ai krb4.mtree scrypto.af scrypto.as crypto.aj krb5.aa scrypto.ag scrypto.at crypto.ak krb5.ab scrypto.ah scrypto.au crypto.al krb5.ac scrypto.ai scrypto.av % cat CHECKSUM.MD5 MD5 (crypto.aa) = 21a7caed7fe026d89f27bc70f39326e5 MD5 (crypto.ab) = 262d9afa063c0bbb3707caf5b1a581f9 MD5 (crypto.ac) = 03bda022337686b15cfa6da0189a1e77 MD5 (crypto.ad) = 14ce9b4faa2e5770f2c68aedb7094ccc MD5 (crypto.ae) = b1bead2decc9e6da1930fc6a7d1528b3 MD5 (crypto.af) = 296176d36a620d744710fce74c776761 MD5 (crypto.ag) = c8d207f74bb4bcf91b0b81155e4d6740 MD5 (crypto.ah) = 6b327235f11f4979a4d80afa442191ba MD5 (crypto.ai) = 7c9a113aba4737c5aadd4443ffc2262a MD5 (crypto.aj) = b17b78ba8ff80155e2e471cfe68e88aa MD5 (crypto.ak) = 91e8a974469f818c0ec165b65c0056b7 MD5 (crypto.al) = e695f85d27217fa1d4a498de4599e991 MD5 (crypto.inf) = e2c02d036c392eadcfbf783621c9d7ad MD5 (crypto.mtree) = fd90e2e35d7a944e091dddf5a557498f MD5 (install.sh) = da31ec9cb344ce54d9873ecfc4d38821 MD5 (krb4.aa) = 02ed52bed52a2ff4e562ae8951586529 MD5 (krb4.ab) = 011b930316980c52ff75a6fa4802108f MD5 (krb4.ac) = 077e7342b59586d802cd026ad58304bd MD5 (krb4.ad) = 4ab31b7583ac3c7b995556060749df75 MD5 (krb4.ae) = 0ada03986b2daf11453bd7193acc113e MD5 (krb4.inf) = ba77a7b0442a1a20ac9ee525ef4e0305 MD5 (krb4.mtree) = 574a343a6a3008722fba688d036edc23 MD5 (krb5.aa) = d1d4c0d40644934e0506aeb452b45cb0 MD5 (krb5.ab) = 89b72bcce2c4f082a32687b0f4365399 MD5 (krb5.ac) = f6f1125efd6445266f83bebde6c60b86 MD5 (krb5.ad) = bfb6860a3c9f026bdb347160f0e28ee3 MD5 (krb5.ae) = b546b1be7cf373417e7b389e1c8ad42e MD5 (krb5.inf) = 19edbc53d1ecf11252496c78a4fdfcfa MD5 (krb5.mtree) = e9a0cb9c1f5cfcad4b7f2996e0cd7d43 You can easily find that "there are no MD5 checksum of scrypto.*, skrb4.*, skrb5.*, and ssecure.*"; src/CHECKSUM.MD5 knows about that, but it's strange that since all scrypto/skrb4/skrb5/ssecure are not in src/. It's easy to fix: 'release.7' target in src/release/Makefile does move all crypto-related source distributions to crypto/ directory. We should recreate src/CHECKSUM.MD5 and crypto/CHECKSUM.MD5 after moving all crypto-related source distributions. *** P.S.: Same story should be applied to 5-current. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fdisk & disklabel dont work!
Okay.
Well, FWIW, fdisk -I does *not* work successfully for me, under any
circumstances I've tried so far.
I have found a work-around, though:
TERM=cons25 # If serial console, set this to vt100
export TERM
/stand/sysinstall nonInteractive=YES partition=all bootManager=standard \
disk=${disk} diskPartitionEditor diskPartitionWrite
Woohah!
Interestingly enough, I see the same complaints about there not being a
disklabel, but my subsequent disklabel commands work. To whit:
disk=${disk}s1
disklabel -r -w $disk auto
disksize=`disklabel $disk | awk -F : '$1 == "sectors/unit" {print $2}'`
[...]
disklabel $disk | grep -v ' c:' > /tmp/mylabel
disklabel -R -B $disk /tmp/mylabel
And then some MAKEDEV, newfs, distributions, packages, config files, etc.
Okay, so I'll need to test this some more, but this is a pleasant
break-through for the evening. One which I hope will hold. :)
This is way screwed up, imho. I might investigate some day as to why
sysinstall can do what fdisk -I can not, but I have some machines that are
overdue for installs. :)
-danny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Disklabel 101?
On Mon, Apr 09, 2001 at 09:16:51AM -0700, David Wolfskill wrote: > OK, since folks are comparing unusual disk layouts, here's one I've been > using on my laptop for the last few weeks (since I got it). Now, this > isn't something that you can tell sysinstall to do directly; more about > that should be at http://www.catwhisker.org/~david/FreeBSD/laptop.html. > > It should also be understood that I'm tracking both -CURRENT and -STABLE > on the machine; that I'm working (as time permits) on some code that > will permit the space pointed to by the 4th MBR "partition table" entry > to be used as a "suspend to disk partition". I just finished building > -CURRENT for today, and did the multi-user boot, so that's what it's > running at the moment. (I'll probably switch to today's -STABLE shortly > after posting this.) > > As in Mike's case, I share the swap space among the kernels; I also share > /var and /common -- basically, everything on what the 3rd "partition tabel" > entry points to. /common is where /usr/local points, as well as /home. > And /usr/obj in each case is a symlink to /common/*/obj (where "*" is one > of "C", "S1", or "S2"). /common/cvs is where I keep my CVS repository. > > It seems to be working OK for me so far. :-) > Well, I'll throw my config in the ring too. My 20G drive is sliced in two, with s1 being 7.5G, and s2 being as large as the rest of the drive. On s2, I have a 250M /, 200M /var, 100M swap, and the remainder (about 10G) as /usr. s1 contains only one partition, /usr/home on ad0s1a. I never saw the need for a separate /tmp, especially since every partition has soft updates enabled. /usr/home is located elsewhere because I switched to FreeBSD from Linux, and I wanted to devote my entire disk to FreeBSD. When I had Linux across the entire drive, I packed it into the first 7.5G, made a BSD slice in the upper region of the drive, installed it, copied my data over from Linux, wiped out Linux, turned the free space into s1, and made that /usr/home. It needs to be 7G for my MP3s. :) I like this. Since /usr always has about 7-8G free, any time I need a new operating system, all I need to do is move /usr/home onto /usr¸ and I have 7G to play with. -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, 9 Apr 2001, Michael R. Rudel wrote: > [... SNIP ...] > > Personally, I don't see a problem with the -CURRENT and -STABLE naming > scheme. As someone said, anybody who can CVSup (not to mention get the > sample CVSup files to work off of) yet not read the rest of the > documentation has other issues. Renaming -CURRENT to -DEV or -DEVEL would > be the equivlent of dulling all the knives in your house so that people > don't cut themselves. A poor analogy. A better one would be labelling the knife drawer something other than knives. > Changing the whole > release process of something that has worked for years isn't going to help > anything Nothing has been suggested about change the *process*. AFAIK, we're talking about the name. Not the process >, people are always going to be confused if you change it - if you > suddenly change the way this shit is named, I'm going to be confused when > 4.4 comes around or whatever. Said confusion, if any, would be temporary and well announced. What is being proposed is a name which helps new people out and which will still make sense long after they've joined te project. > Just chill, and instruct people to Read The > Fine Manual. AFAIK, everyone is chilled. As for discarding the issue with a RTFM, that's avoiding the issue altogether and will not achieve anything. Reasoned discussion, whch is what I thought we were doing, will. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, Apr 09, 2001 at 10:26:50AM -0500, Christopher Schulte wrote: > > Change the designation just because some admins don't know how to RTFM? I > don't think so... They fu*ked up. Plain and simple. -CURRENT makes sense, > and more importantly is documented for those who take the time to look. With self-documenting labels documentation becomes unnecessary. Markus -- Markus Holmberg | Give me Unix or give me a typewriter. [EMAIL PROTECTED] | http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
On Mon, 9 Apr 2001, Christopher Schulte wrote: > At 03:45 AM 4/10/2001 +1200, Dan Langille wrote: > >Give meaningful and widely used names to things which people are familiar > >with. > > -CURRENT fits all those requirements. In this case, the familiarity is reduced to those familiar with the project. Witness the frequency with which the confusion arises. > > > I'm not as hot about the BETA designation, but generally feel it should > > > be left alone simply because it's documented, and thus should NOT be a > > > problem. > > > >By this designation, we could call a brake a clutch and get away with it > >because it's all documented. The problem is not with the documentation. > >It's with the name. > > Documentation is not the only factor. The name was chosen for a *reason*, > to convey a point. It's choice was not arbitrary. Is this from experience or are you guessing? > And it's since been > accepted by the development and administrative community. The people already on the project understand. They have been "indoctrinated" for lack of a better term. It's the new people which have the trouble. Perhaps with a better name that trouble could be easily avoided. > Question being: Now, are we to a point where that accepted name needs > to be reevaluated for the sake of general consensus, need or desire. > That's the real question, IMHO. I think so. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
> By this designation, we could call a brake a clutch and get away with it > because it's all documented. The problem is not with the documentation. > It's with the name. That's a nice pat answer, but the problem is that for every value of "name" we propose, somebody comes forward and says "But that confuses me." We can't call it BETA, we can't call it STABLE, we can't call it RC, we can't call it PRERELEASE, because each and every one of those have had push-back from people who said it would conflict with previous definitions they hold dear. Given that, chances are excellent that any other halfway logical names we come up with will suffer from the same problem. The real problem here is that we're trying to cater to the lowest common denominator, which is stupid people who leap before they look and then blame someone else for the injuries they sustain. It is for those very same people that legal liability forced McDonalds to write "Warning: This is called hot coffee. That means it is Hot. You should never, ever dump it into your crotch or on any other part of your body which is intended to remain unscalded. Did we mention that it's very hot?" If we were McDonalds (or Microsoft for that matter), we would also stop providing access to -stable and -current entirely because it had been statistically proven that the lower percentile out there was doing the equivalent of pouring coffee in their laps and we didn't want the liability. However, we're not them and I don't think we should try to twist ourselves into those kinds of shapes. Both -current and -stable are aimed at something other than "the masses" (for them, there are -releases in handy jewel-cased form) and are well documented as such in our handbook. The masses simply need to learn to stay out of those areas. To use another analogy, FreeBSD is not just a building, it's a building with a perpetual construction site next to it which is knocking up another building. As long as the office workers stay in their building, things are good. When they wander onto the construction site without hard-hats or an invitation for a guided tour, however, they should expect to get either squished or seriously yelled at and chased off the site by the first construction worker they run into. A construction site also generally has fences around it to stop the truly cerebrally challenged from crawling under the pile-driver, perhaps we need the same. I got it - unless you provide a special secret flag to it, cvsup always uses its GUI mode and presents the user with a disclaimer and release form which needs to be agreed to first. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
[... SNIP ...] Personally, I don't see a problem with the -CURRENT and -STABLE naming scheme. As someone said, anybody who can CVSup (not to mention get the sample CVSup files to work off of) yet not read the rest of the documentation has other issues. Renaming -CURRENT to -DEV or -DEVEL would be the equivlent of dulling all the knives in your house so that people don't cut themselves. As for -BETA, there isn't really a problem with this either, if you take it apart and look at it. >From the Hacker's Dictionary, the definition of 'beta' is as follows: 1. Mostly working, but still under test; usu. used with `in': `in beta'. In the Real World, systems (hardware or software) software often go through two stages of release testing: Alpha (in-house) and Beta (out-house?). Beta releases are generally made to a group of lucky (or unlucky) trusted customers. 2. Anything that is new and experimental. "His girlfriend is in beta" means that he is still testing for compatibility and reserving judgment. 3. Flaky; dubious; suspect (since beta software is notoriously buggy). x.x-BETA is ... notoriously buggy. It has bugs, that's the point of the beta - to work the bugs out. If it didn't have bugs (that we knew about), it'd be -RELEASE. -STABLE is generally (with some execptions), more stable than -RELEASE, because it is a -RELEASE version with both ongoing bugfixes and (minor) new features. A release canidate is an almost ready release. Personally, I think these should be named GAMMA, DELTA, ... because that continues with the whole ALPHA or BETA trend. All these designitions do is indicate various stages of code freeze, and this is all documented places. Changing the whole release process of something that has worked for years isn't going to help anything, people are always going to be confused if you change it - if you suddenly change the way this shit is named, I'm going to be confused when 4.4 comes around or whatever. Just chill, and instruct people to Read The Fine Manual. -- Michael R. Rudel * 734.417.4859 * [EMAIL PROTECTED] AOL AIM: ATSTheory * Cell e-mail: [EMAIL PROTECTED] Network Engineer, Pinckney Community Schools Systems Engineer, NourDesign Corp Principal Engineer, Michael R. Rudel Consulting Authorized Representative, Charter Communications -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: BDECFLAGS break current 4.x-stable build
On Mon, Apr 09, 2001 at 04:09:11PM +0200, Matthias Andree wrote: > 4.x-stable Checked out today (2001-04-09) at 13:00 UTC > > * > NOTE: _ALL_ problems mentioned below disappear with BDECFLAGS removed > from CFLAGS, thus a default build will not encounter these. > * Submit patches to fix them, then. BDECFLAGS is there for developers to work on code correctness and possible bugs resulting from language misuse (or general gcc pickiness which doesn't actually involve code bugs). It doesn't change the code generated by gcc. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Releases
At 03:45 AM 4/10/2001 +1200, Dan Langille wrote: >Give meaningful and widely used names to things which people are familiar >with. -CURRENT fits all those requirements. > > I'm not as hot about the BETA designation, but generally feel it should > > be left alone simply because it's documented, and thus should NOT be a > > problem. > >By this designation, we could call a brake a clutch and get away with it >because it's all documented. The problem is not with the documentation. >It's with the name. Documentation is not the only factor. The name was chosen for a *reason*, to convey a point. It's choice was not arbitrary. And it's since been accepted by the development and administrative community. Question being: Now, are we to a point where that accepted name needs to be reevaluated for the sake of general consensus, need or desire. That's the real question, IMHO. --chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
