Yes, there will be conflicts on just about every file. There is a
significant mainline after the initial import, and the "-j" merge conflicts
on the $Id$ lines... Yuck! (These comments apply to the rest of the
imports)
Obtained from: Paul Vixie <paul@vix.com>
Note that this was done by selective patching from diffs, to not conflict
with the 4.4bsd base code.. This was *not* a trivial task.. I have been
testing this code (apart from cosmetic changes) in my libc for a while now.
Obtained from: Paul Vixie <paul@vix.com>
Note: this was done by selective patching from diffs by hand, in order
to not conflict with the 4.4BSD base code. Beta9 was done the same way.
Obtained from: Paul Vixie <paul@vix.com>
Claim the major numbers (before sombedoy else jumps in again and
claims the slots for his foocd driver :-), install all the hooks that
are required.
While i've been at this, i've cleaned up some of the routines at the
end of i386/conf.c; all the importers of the latest CDROM drivers
forgot to fill in the appropriate information. The `ata' driver
(vapourware?) does only occupy a slot in the bdevsw[] array, btw.
The actual import of the code does require a minor change in the SCSI
subsystem, and i want to have this reviewed by Peter first, so it will
be deferred for some days. The driver is already working for me
though.
Submitted by: akiyama@kme.mei.co.jp (Shunsuke Akiyama)
Jordan, you might wish to update sysinstall's builtin knowledge, too.
They are also offering r/o NFS access, will this be interesting for
us? (sysinstall)
that this is a superset of cdplay, and perhaps it's time to send cdplay
into the bit bucket if this works well. According to the docs, it has
a friendlier command structure, command line interface etc.
Submitted by: Serge Vakulenko <vak@cronyx.ru>
change, but I've been testing this on thud and silvia for quite a
while, also I haven't gotten any bug reports from the ports list, so
I'm going to let it loose!
It cleans up this file quite a bit, now I can go in and start adding
some more "interesting" things.... ;)
calls.
Found by: gcc -Wstrict-prototypes after I supplied some of the 5000+
missing prototypes. Now I have 9000+ lines of warnings and errors
about bogus conversions of function pointers.
Note that conf.c, although there was an import conflict, it did not
require intervention, as it was the $Id$ tag. It would have become
rev 1.8 on checkout so there's no point changing it from 1.7 to
1.1.1.3 as the "-j" option wanted to do.. Trust me.. :-)
page. I tried all three modes (rwhod, rwhod -m, rwhod -m 32) on a machine
with 2 ethernet interfaces and they all worked.
Submitted by: Bill Fenner <fenner@parc.xerox.com>
Note, I tested this on a NEC Versa, IBM 750C, and a IBM 755CX w/out
problems. The card still works fine in TP mode.
Submitted by: schwarz@alpharel.com (Steve Schwarz)
Reviewed by: jleppek@suw2k.ess.harris.com (James Leppek)
oo
Turns out, it's pretty important if you use PAX for backup. In the man
page for PAX, there is an error (OK, we could call it a "potentially
catastrophic incompleteness"). It reads:
> The command:
>
> pax -r -v -f filename
>
> gives the verbose table of contents for an archive stored in filename.
Yup, it does do that. With a side effect: it also _replaces_ all the
files that come in from the archive. As is my custom, I did my
backup-validation real soon after the backup was written. Precisely
because I've seen the same sort of thing happen on other systems. So all
that file-restoring didn't do a lot of damage. Probably helped my
fragmentation somewhat (aha, an online defragger?) It did confuse one
hapless user, who lost an email message he _knew_ he hadn't deleted.
Apparently the system restored the file as of just before that critical
message came in.
The correct entry should read:
> The command:
>
> pax -v -f filename
>
> gives the verbose table of contents for an archive stored in filename.
Submitted by: John Beckett <jbeckett@southern.edu> via the BSDI mailing list
Remove some rare-used semigraphics from VT100 entry, it really helps many
not-fully compatible emulators and don't degradate original vt100 much.
Add VT200 keys set to VT100 k1-k4, it not affects original VT100 since no one
program tests keys presense, but helps emulators to work
1: It stops invalid files being created in the cvs tree
2: It stops the import from aborting without mailing a commit message..
The first is simple, it opens the file for reading before touching the
repository, and the second catches the pieces when it hits an unreadable
file rather than just aborting mid-way through, leaving the repository in
a bit mess.
Reviewed by: rgrimes
