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}
:
: My take on this
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 to
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
On Mon, 24 Apr 2000, Garrett Wollman wrote:
On Mon, 24 Apr 2000 22:09:14 -0500, Richard Wackerbarth [EMAIL PROTECTED] 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
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 the
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 to be
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 you
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 tell
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 words:
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
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 can even
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
-stable.
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
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 depends on
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
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, 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 it
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" it.
The fact that it is only necessary to
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 them with
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
sandbox", that's what it will be. I
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 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 sometimes
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
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:
: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 release
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 "stale
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.
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 PROTECTED]
To Unsubscribe: send mail
uded, 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
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
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.
--
Richard Wackerbarth
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTEC
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 large directory hierarchy like
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
'load
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" we'd have to
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
CTED]
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 Dell Latitude
Help!
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 CANNOT
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, again,
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
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
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 that having /usr/src isn't required to build
ports
On Thu, 1 Apr 1999, Satoshi - the Wraith - Asami wrote:
* From: Richard Wackerbarth r...@dataplex.net
* very short sided.
sighted :
Yes, a slight transfer error between my brain and 'sendmail'.
* There are two distinct environments to be considered.
* The HOST
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/03/22
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.
However, I fear that you need a bit more logic
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 we have
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.conf?
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/cc
# cd /usr/src
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 must it
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
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 in
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
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
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/defaults that
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 actually..
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 the
56 matches
Mail list logo
