On Sun, 02 Jul 2000, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "David O'Brien" writes:
> : On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
> : > : cd blah is currently
> : > : cd ../../compile/${KERNNAME}
> : > : it becomes
> : > : cd /usr/obj/`pwd`/${KERNNAME}
> : >
> : > M
On Wed, 26 Apr 2000, you wrote:
> *Bzzzt*. Wrong. You only get the old history during the intial cvsup.
> And since the most recent revisions are stored at the beginning of an RCS
> file, you don't pay for this on cvs operations except for 'cvs log' and
> other operations dealing with the hist
On Wed, 26 Apr 2000, you wrote:
> Any further discussion from you on this point that doesn't include code
> is totally and completely without value. You haven't proven the value of
> your suggestion to _anyone's_ satisfaction, so no one is going to do it
> for you. So if you're not willing
On Tue, 25 Apr 2000, Jordan K. Hubbard wrote:
> > And if I put up, will you (the organization) use it? It's certainly too
> > much work to prove the obvious. I don't have to convince myself of
> > anything. The only value accrues if it gets used.
>
> Erm, haven't we been here with you before? I c
On Tue, 25 Apr 2000, Matthew Hunt wrote:
> Maintaining a CVS repository is necessary only if you are working
> on the code,
I disagree. Anyone who attempts to run "-current" on a regular basis
needs the recent history to cobble together a working system.
It is also very helpful if you are a "te
On Tue, 25 Apr 2000, Kris Kennaway wrote:
> On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> > Actually, I didn't start this. Someone else brought up the idea.
>
> ...and quickly decided it was not worthwhile.
Yes, the developers do a good job of repressing opinions that di
On Tue, 25 Apr 2000, Kris Kennaway wrote:
> On Tue, 25 Apr 2000, Wilko Bulte wrote:
> > OK. But you do have to uniquely identify the binary that needs to be
> > patched. So, my question is when you generate 10x the same binary, will
> > all these 10 binaries have the same MD5 checksum? In other wo
On Tue, 25 Apr 2000, you wrote:
> I told myself I wouldn't get into this debate with you again, Richard, but
> you're not listening. The vast majority (all? I might have missed one) of
> the other respondants
Actually, I didn't start this. Someone else brought up the idea.
> P.S. Please don't t
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> In other words: if people did
> a local buildworld once on a -release sourcetree will all the executables
> have the same MD5 as the ones on the -release cdrom?
If you are using someone's patches, you must be patching the files that they
provided. If yo
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> > On a similar note: I think one of serious drawbacks of FreeBSD's model
> > for updating and bugfixing the stable branch is 'make world'. It's very
> > inefficient and cumbersome way to do this on production machines. STABLE
> > is stable enough for us t
On Tue, 25 Apr 2000, Nate Williams wrote:
> No-one needs to grab a repository, unless they're looking at history.
> Just use CVSup to grab the latest bits, no need to grab the entire
> history.
I find it virtually impossible to work with anything but the most stable
without the recent part of t
On Mon, 24 Apr 2000, Garrett Wollman wrote:
> < said:
> > You confuse the argument for SOME complete repositories with
> > the necessity that ALL (or at each most) repositories be so extensive.
>
> You're welcome to remove whatever history you like from your personal
> copy.
Not if I want to k
On Mon, 24 Apr 2000, you wrote:
> I'd like to add that it can be particularly important when legal
> questions arise.
You confuse the argument for SOME complete repositories with
the necessity that ALL (or at each most) repositories be so extensive.
To Unsubscribe: send mail to [EMAIL PROTECT
On Mon, 24 Apr 2000, you wrote:
> On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote:
> > I want to bring up a suggestion. I just want a little bit of argument on
> > it ... and if you're violently opposed, just say so, that's fine.
>
> I'm "violently opposed". :-)
>
> > While folks do
On Mon, 24 Apr 2000, Chuck Robey wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history more than 3 (or
On Mon, 24 Apr 2000, you wrote:
> > On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
> > > That is also partly why you are also lacking the respect and support of
> > > a wider audience. If you act like FreeBSD is just a "developer's
> >
On Mon, 24 Apr 2000, you wrote:
> > Seriously, perhaps we should consider putting optional pieces of the
> > kernel
>
> Firmware for a SCSI adapter is not optional. At least not on some of the
> Alpha machines that download out-of-date firmware from their SRMs so depend
> on the driver to load th
On Mon, 24 Apr 2000, you wrote:
> On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
> > >From the USER's perspective, anything that requires me to as much as
> > > reload
> >
> > a module/program that I have already installed "breaks&
On Mon, 24 Apr 2000, Julian Elischer wrote:
> This seems well thought out and I certainly agree that we don't need
> DIFFs of firmware.
> I wonder if we can somehow "cheat time" and get that 13MB file out of
> the source tree and retro-actively tag the new scheme so
> that we don't have to carry
On Mon, 24 Apr 2000, Alfred Perlstein wrote:
> I think as a whole we need to evaluate the use of macros, they're
> one of the major problems with changes like this and several people
> have come forward over time with strong numbers showing that the
> code bloat causes that comes with overuse of
On Mon, 24 Apr 2000, Frank Mayhar wrote:
> 1. 4.0 hasn't been out long enough for there to be any significant support
>for it in proprietary systems. It takes more lead time than this.
So make the change and release it as FreeBSD5. Save the big changes for
something called FreeBSd6 or Free
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
> > I don't think it was ever recommended that you upgrade your kernel
> > without upgrading and rebuilding the modules (better still, world) at
> > the same time. So this wouldn't really have an adverse effect, would it?
>
> I believe that it depe
On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote:
> I don't think it was ever recommended that you upgrade your kernel
> without upgrading and rebuilding the modules (better still, world) at
> the same time. So this wouldn't really have an adverse effect, would it?
Such a policy is totally unac
On Mon, 24 Apr 2000, Matthew Dillon wrote:
> : However, I consider your SMP changes VERY destablizing; they BREAK
> : lots of modules :-(
>
> Huh? No they don't. They simply require recompiling the modules. If
> they actually broke the modules I wouldn't be trying to MFC it to
> -st
On Sun, 23 Apr 2000, Matthew Dillon wrote:
>
> :Rather than break the FreeBSD4 modules over which you have no control,
> :perhaps your arguments should be used to accelerate the 5.0 release
> :and make 4.x a short lived branch.
>
> I don't think this is possible. 4.0 is the most stable releas
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :In that case I have a strong objection to the SMP patchset being
> :merged to 4.0. I have kernel modules in object format only that
> :are working now, which this would break :-(.
> :
> :Rod Grimes - KD7CAX @ CN85sl - (RWG25)
> : [EMAIL
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> If core wants to change the current rules, that's fine by me. As I
> said before I think the breakage that we thought would happen with 5.x
> due to the BSDI merger that prompted the loose rules for 4.x is
> overrated, and the rules should
On Thu, 20 Apr 2000, Maxim Sobolev wrote:
> > Then, we could add an option
> > "make modules" and "make install_modules" so that they could be
> > built/installed with the kernel.
> >
> > After all, modules ARE a part of the kernel...
>
> Looks like *really* nice idea. This would allow to solve "s
On Mon, 03 Apr 2000, Donn Miller wrote:
> I think we ought to re-examine the definition of load average. By
> load, we mean an actual load on the cpu, and waiting processes aren't
> really exerting a cpu load. So, by that reasoning I say waiting
> processes don't count.
I think you have an inc
On Wed, 15 Mar 2000, Ron 'The InSaNe One' Rosson wrote:
> Well,
> Here we are again. Another branch off the FreeBSD code and the mailing
> lists are going to be confusing. CURRENT is starting to see posts of the
> 5.0 code and STABLE is starting to see things of 4.0. I read CURRENT and
> STABLE
On Tue, 14 Mar 2000, Vallo Kallaste wrote:
> Strange, I always thought the -current list is for general issues
> related to -current branch ...
We really should have a new mailing list since we have an additional branch.
I'll again voice the opinion that the naming of the lists is sub-optimal.
myself included, are advocating making FreeBSD into a small set
of ports!
I guess that doesn't affect very many people :-)
--
Richard Wackerbarth
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
st as they do now.
However, instead of distributing that tree, we would derive (automatically) the
level 2 tarballs and distribute them. The top level Makefile in /usr/ports/
would expand the level 2 build tree and continue down into it just as it does
now.
--
Richard Wackerbarth
[EMAIL PROTECTE
for browsing
before we go online to actually fetch the required files?
--
Richard Wackerbarth
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Thu, 10 Feb 2000, Archie Cobbs wrote:
> Richard Wackerbarth writes:
> > There are two problems in the size of the ports system.
> > 1) The large number of inodes.
>
> I don't see the ports tree as the problem. The problem is that
> FreeBSD does not handle a very l
t we make a `port` collection of
the FreeBSD kernel and standard userland utilities? That would lead to
the next step of having the "standard distribution" become just a meta package
much like 'kde' pulls in 'kdebase', 'kdeutils', 'kdegraphics', etc.
--
On Thu, 03 Feb 2000, you wrote:
> When we do a 'make install' on the kernel, it automatically copies
> /kernel to /kernel.old, and copies the new kernel in ... is there no way
> of extending this to the modules?
>
> The one thing I was thinking might be to have it so that if you
> 'l
On Mon, 31 Jan 2000, you wrote:
> On Sun, 30 Jan 2000, John Polstra wrote:
>
> > > > It's source-dir is called "xinstall" btw.
> > > Why is the source called "xinstall"?
> >
> > To avoid colliding with the standard make target "install". If we
> > had utilities named "all", "depend", and "clean
On Mon, 24 Jan 2000, Rodney W. Grimes wrote:
> This does not need to really be a wrapper around cvs, folks should run
> a tool 1 time to pick the best guess as to what server they should be
> using, stick that value in thier cvsup file and be done with it. If
> jdp calls for a ``this server is b
On Tue, 04 Jan 2000, Marcel Moolenaar wrote:
> Ok, but this means that we won't install doscmd with X11 support
> anymore. The user has to rebuild doscmd itself to have X11 support. In
> that case, it's better to have it in the ports collection...
I agree. Further, if X is not found, the port ca
On Wed, 27 Oct 1999, David O'Brien wrote:
> IF you are going to run -CURRENT, you need to read this list.
> (/me wonders how many MORE times we are going to have to say this because
> of the signal changes...)
So why not automate a warning?
In the current Makefiles, make the build depend upon the
L PROTECTED]>
Hi,
You should write this question to [EMAIL PROTECTED], there was
some discusion about this.
Ales
- Original Message -
From: Richard Wackerbarth <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 13, 1999 5:09 PM
Subject: /dev/smb0 on D
On Sun, 03 Oct 1999, you wrote:
> Richard Wackerbarth wrote:
> > Why isn't the kernel BUILT automatically as a part of "buildworld"?
> > Except for the fact that the object directory is in the wrong place, why isn't
> > a kernel just like any other module
> On 2 October 1999 at 9:45, "Rodney W. Grimes" <[EMAIL PROTECTED]> wrote:
>
> > When did we go wrong and start saying that users should build the world
> > before building a new kernel?If it was ``I'' that said it, I full
> > retract any such statement, I was WRONG!. It may have been said i
On Thu, 30 Sep 1999, Marcel Moolenaar wrote:
> Richard Wackerbarth wrote:
> >
> > > Sub-problem A (syscalls) can be easily handled if the syscalls are added
> > > to a -stable kernel.
> >
> > Wrong. I CANNOT rebuild the kernel that runs my build machine.
On Thu, 30 Sep 1999, Marcel Moolenaar wrote:
> Sub-problem B (sigframe) doesn't need to be handled, because:
> 1. none of the tools require ...
Correct, this is a "non-problem".
> Sub-problem A (syscalls) can be easily handled if the syscalls are added
> to a -stable kernel.
Wrong. I CANN
On Wed, 29 Sep 1999, Garrett Wollman wrote:
> < said:
>
> > I believe this must be fixed.
>
> There is no way it can be ``fixed''. That's Just The Way It Is. I'm
> sorry that you're having a problem with this. Nobody ever said
> keeping -current would be easy.
I have to agree with Rod that w
On Wed, 12 May 1999, Mike Smith wrote:
> > This option should automatically select the appropriate sources
> > which is compiled into kernel, according to the source is needed
> > only in UP case, or only in SMP case, or both. This is what
> > oldconfig and newconfig does.
>
> This is, aga
I wish :-(
It seems that some people think that it is OK to make changes to stable
even though those changes break things which used to work.
IMHO, branches of the kernel SHOULD be like shared libraries.
(It is OK to ADD previously absent features or CORRECT internal errors,
but NOT OK to delete
On Thu, 1 Apr 1999, Satoshi - the Wraith - Asami wrote:
> * From: Richard Wackerbarth
> * very short sided.
> sighted :>
Yes, a slight transfer error between my brain and 'sendmail'.
> * There are two distinct environments to be considered.
> *
On Thu, 1 Apr 1999, Chuck Robey wrote:
> On Thu, 1 Apr 1999, Richard Wackerbarth wrote:
>
> > The natural tag for the TARGET would be in
> > /usr/src/include. However, I can see some problems with this for
> > the ports tree.
>
> Richard, don't forget tha
I have to agree that the problem is real.
However, let me point out that a "one identifier" solution is
very short sided.
There are two distinct environments to be considered.
The HOST environment and the TARGET environment.
For convience, we should also consider a TOOLSET
environment which is a c
On Mon, 22 Mar 1999, John Baldwin wrote:
> > An alternate, and perhaps cleaner approach would be to always suck in
> > /etc/defaults/rc.conf and /etc/rc.conf. Then suck in those files specified
> > in ${additional_rc_conf_files}.
>
> That would work, but then we have two includes everywhere that
On Mon, 22 Mar 1999, John Baldwin wrote:
>
> On 22-Mar-99 Richard Wackerbarth wrote:
> > There is a problem with this approach.
> >
> > /etc/defaults/rc.conf defines ${rc_conf_files}
> > However, I have no chance to override it before it is used.
> >
>
On Sun, 21 Mar 1999, Jordan K. Hubbard wrote:
> Index: netstart
> ===
> RCS file: /home/ncvs/src/etc/netstart,v
> retrieving revision 1.53
> diff -u -u -r1.53 netstart
> --- netstart 1999/02/10 18:08:16 1.53
> +++ netstart 1999/0
Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
Shouldn't that file simply be definitions of variables?
IMHO, the "logic" should be in "rc" itself.
On Sat, 20 Mar 1999, Scot W. Hetzel wrote:
> What does everyone think about using this at the end of
> /etc/defaults/rc.c
> At 01:28 PM 3/1/99 -0800, Jordan K. Hubbard wrote:
> >It really does appear to be a simple matter of first making egcs "take over"
> >the system compiler:
> >
> ># cd /usr/ports/lang/egcs
> ># make all install PREFIX=/usr
> ># ln -fs /usr/bin/eg++ /usr/bin/c++
> ># ln -fs /usr/bin/egcc /usr/bin/c
On Wed, 10 Feb 1999, John Fieber wrote:
> On Wed, 10 Feb 1999, jack wrote:
>
> > If /etc/rc.conf only contains changes from the defaults when
> > man something_or_other tells the user to find and edit
> > something_or_other_flags in /etc/rc.conf the entry won't be
> > there to edit.
>
> Why m
But, I would not expect/allow "defaults" to be the mechanism
which includes the "real" values. Perhaps this should be pushed
into the script that will source both.
On Wed, 10 Feb 1999, Sheldon Hearn wrote:
> > The only difference is the addition of a "no touchees" reference copy
> > in /etc/defaul
I tend to prefer that the editable knobs be kept together.
The uneditable scripts and the defaults can go together.
If you are going to divide things, I don't see why you should
put uneditable scripts with editable knobs and apart from
uneditable knobs.
On Tue, 9 Feb 1999, RT wrote:
> I kinda like
I understand the scaling issue.
However, I like to keep related things in one place.
Perhaps we need to move ALL the rc files into a common
directory.
As for the "read-only" argument, I recommend, for those
who wish to separate them, symbolic links from the read
only area to a writable area. When t
Personally, I have to side with Matt.
I like to have ALL of the files in one directory.
That way I can "grep ntpd /etc/rc*" and find ALL the line that are likely
to affect it. Moving some of the files into another directory just
complicates things.
I like the idea of having all the "default knobs"
Jordan,
I object to the idea that the selection of which dhcp client
is being made on the basis that David has commit privledges
and I do not. Further, it is clear that David has not used a
recent release of the isc client and is biasing his opinion
with false assertions.
It is my opinion that we
On Tue, 9 Feb 1999, Daniel O'Connor wrote:
>
> On 09-Feb-99 Charlie ROOT wrote:
> > Further, the assertion that it is easier to configure the WIDE client is
> > WRONG. The ISC CLIENT requires NO configuration. I don't see how anything
> > can be simpler. :-)
> Hmmm.. This annoyed me actual
On Thu, 4 Feb 1999, Daniel C. Sobral wrote:
> Rod Taylor wrote:
> > I've often wondered this, but why is it that every network card has a
> > different
> > 'name'.
> > xl0, rl0, vr0, ed0, etc. etc. etc
> The best solution would be hardwiring the names, but in that case it
> doesn't matter what are
65 matches
Mail list logo
