diff --git a/en/handbook/authors.ent b/en/handbook/authors.ent
index 80e0daca31..374e7dca88 100644
--- a/en/handbook/authors.ent
+++ b/en/handbook/authors.ent
@@ -1,326 +1,338 @@
abial@FreeBSD.ORG">
ache@FreeBSD.ORG">
adam@FreeBSD.ORG">
alex@freebsd.org">
amurai@FreeBSD.ORG">
andreas@FreeBSD.ORG">
archie@FreeBSD.ORG">
asami@FreeBSD.ORG">
ats@FreeBSD.ORG">
awebster@pubnix.net">
bde@FreeBSD.ORG">
billf@FreeBSD.ORG">
brandon@FreeBSD.ORG">
brian@FreeBSD.ORG">
cawimm@FreeBSD.ORG">
charnier@FreeBSD.ORG">
chuckr@glue.umd.edu">
chuckr@FreeBSD.ORG">
cracauer@FreeBSD.ORG">
csgr@FreeBSD.ORG">
cwt@FreeBSD.ORG">
danny@FreeBSD.ORG">
darrenr@FreeBSD.ORG">
dg@FreeBSD.ORG">
davidn@blaze.net.au">
dburr@FreeBSD.ORG">
des@FreeBSD.ORG">
dfr@FreeBSD.ORG">
dillon@FreeBSD.ORG">
dima@FreeBSD.ORG">
+dirk@FreeBSD.ORG">
+
Dirk.vanGulik@jrc.it">
dt@FreeBSD.ORG">
dwhite@FreeBSD.ORG">
dufault@FreeBSD.ORG">
dyson@FreeBSD.ORG">
perhaps@yes.no">
ejc@FreeBSD.ORG">
erich@FreeBSD.ORG">
faq@freebsd.org">
fenner@FreeBSD.ORG">
flathill@FreeBSD.ORG">
+foxfair@FreeBSD.ORG">
+
fsmp@FreeBSD.ORG">
+gallatin@FreeBSD.ORG">
+
gclarkii@FreeBSD.ORG">
gena@NetVision.net.il">
ghelmer@cs.iastate.edu">
gibbs@FreeBSD.ORG">
mjacob@FreeBSD.ORG">
gj@FreeBSD.ORG">
gpalmer@FreeBSD.ORG">
graichen@FreeBSD.ORG">
grog@FreeBSD.ORG">
gryphon@healer.com">
guido@FreeBSD.ORG">
hanai@FreeBSD.ORG">
handy@sxt4.physics.montana.edu">
helbig@FreeBSD.ORG">
-hm@kts.org">
+hm@FreeBSD.ORG">
hoek@FreeBSD.ORG">
hosokawa@FreeBSD.ORG">
hsu@FreeBSD.ORG">
imp@FreeBSD.ORG">
itojun@itojun.org">
jb@cimlogic.com.au">
jdp@FreeBSD.ORG">
jehamby@lightside.com">
jfieber@FreeBSD.ORG">
james@nexis.net">
jgreco@FreeBSD.ORG">
jhay@FreeBSD.ORG">
jkh@FreeBSD.ORG">
jkoshy@FreeBSD.ORG">
jlemon@FreeBSD.ORG">
john@starfire.MN.ORG">
jlrobin@FreeBSD.ORG">
jmacd@FreeBSD.ORG">
jmb@FreeBSD.ORG">
jmg@FreeBSD.ORG">
jmz@FreeBSD.ORG">
joerg@FreeBSD.ORG">
john@FreeBSD.ORG">
jraynard@freebsd.org">
jseger@freebsd.org">
julian@FreeBSD.ORG">
jvh@FreeBSD.ORG">
karl@FreeBSD.ORG">
kato@FreeBSD.ORG">
kelly@fsl.noaa.gov">
ken@FreeBSD.ORG">
kjc@FreeBSD.ORG">
kuriyama@FreeBSD.ORG">
lars@FreeBSD.ORG">
ljo@FreeBSD.ORG">
luoqi@FreeBSD.ORG">
markm@FreeBSD.ORG">
martin@FreeBSD.ORG">
max@FreeBSD.ORG">
mark@vmunix.com">
mbarkah@FreeBSD.ORG">
mckay@FreeBSD.ORG">
mckusick@FreeBSD.ORG">
md@bsc.no">
+mks@FreeBSD.ORG">
+
motoyuki@FreeBSD.ORG">
mph@FreeBSD.ORG">
mpp@FreeBSD.ORG">
msmith@FreeBSD.ORG">
nate@FreeBSD.ORG">
nectar@FreeBSD.ORG">
+newton@FreeBSD.ORG">
+
n_hibma@FreeBSD.ORG">
nik@FreeBSD.ORG">
nsj@FreeBSD.ORG">
obrien@FreeBSD.ORG">
olah@FreeBSD.ORG">
opsys@open-systems.net">
paul@FreeBSD.ORG">
pb@fasterix.freenix.org">
pds@FreeBSD.ORG">
peter@FreeBSD.ORG">
phk@FreeBSD.ORG">
pjchilds@imforei.apana.org.au">
proven@FreeBSD.ORG">
pst@FreeBSD.ORG">
rgrimes@FreeBSD.ORG">
rhuff@cybercom.net">
ricardag@ag.com.br">
rich@FreeBSD.ORG">
rnordier@FreeBSD.ORG">
roberto@FreeBSD.ORG">
rse@FreeBSD.ORG">
sada@FreeBSD.ORG">
scrappy@FreeBSD.ORG">
se@FreeBSD.ORG">
sef@FreeBSD.ORG">
+simokawa@FreeBSD.ORG">
+
smace@FreeBSD.ORG">
smpatel@FreeBSD.ORG">
sos@FreeBSD.ORG">
stark@FreeBSD.ORG">
stb@FreeBSD.ORG">
steve@FreeBSD.ORG">
swallace@FreeBSD.ORG">
tedm@FreeBSD.ORG">
tegge@FreeBSD.ORG">
tg@FreeBSD.ORG">
thepish@FreeBSD.ORG">
torstenb@FreeBSD.ORG">
truckman@FreeBSD.ORG">
ugen@FreeBSD.ORG">
uhclem@FreeBSD.ORG">
ulf@FreeBSD.ORG">
vanilla@FreeBSD.ORG">
wes@FreeBSD.ORG">
whiteside@acm.org">
wilko@yedi.iaf.nl">
wlloyd@mpd.ca">
wollman@FreeBSD.ORG">
wosch@FreeBSD.ORG">
wpaul@FreeBSD.ORG">
yokota@FreeBSD.ORG">
diff --git a/en/handbook/bibliography/chapter.sgml b/en/handbook/bibliography/chapter.sgml
index a549e0ca67..64de53ef79 100644
--- a/en/handbook/bibliography/chapter.sgml
+++ b/en/handbook/bibliography/chapter.sgml
@@ -1,506 +1,531 @@
BibliographyWhile the manual pages provide the definitive reference for
individual pieces of the FreeBSD operating system, they are notorious
for not illustrating how to put the pieces together to make the whole
operating system run smoothly. For this, there is no substitute for a
good book on UNIX system administration and a good users'
manual.Books & Magazines Specific to FreeBSDInternational books &
Magazines:Using
FreeBSD (in Chinese).FreeBSD for PC 98'ers (in Japanese), published by SHUWA
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.FreeBSD (in Japanese), published by CUTT. ISBN
4-906391-22-2 C3055 P2400E.Complete Introduction to FreeBSD (in Japanese), published by Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E.Personal UNIX Starter Kit FreeBSD (in Japanese), published by ASCII. ISBN 4-7561-1733-3 P3000E.FreeBSD Handbook (Japanese translation), published by
ASCII. ISBN
4-7561-1580-2 P3800E.
- FreeBSD mit Methode (in German), publiched by Computer und
- Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-93211-31-0.
+ FreeBSD mit Methode (in German), published by Computer und
+ Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.
+
+
+ FreeBSD
+ Install and Utilization Manual (in Japanese),
+ published by Mainichi
+ Communications Inc..
+ English language books &
Magazines:The
Complete FreeBSD, published by Walnut Creek
CDROM.Users' GuidesComputer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-075-9Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-076-7UNIX in a Nutshell. O'Reilly
& Associates, Inc., 1990. ISBN
093717520XMui, Linda. What You Need To Know When You Can't
Find Your UNIX System Administrator. O'Reilly
& Associates, Inc., 1995. ISBN 1-56592-104-6Ohio State
University has written a UNIX Introductory Course which is available online in HTML and postscript format.
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ User's Reference Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0088-4
+ P3800E.
+ Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc.,
1997. ISBN 1-56592-236-0Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-080-5Costales, Brian, et al. Sendmail, 2nd
Ed. O'Reilly & Associates, Inc., 1997. ISBN
1-56592-222-0Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly &
Associates, Inc., 1995. ISBN 1-56592-127-5Hunt, Craig. TCP/IP Network
Administration. O'Reilly & Associates, Inc.,
1992. ISBN 0-937175-82-XNemeth, Evi. UNIX System Administration
Handbook. 2nd Ed. Prentice Hall, 1995. ISBN 0131510517Stern, Hal Managing NFS and NIS
O'Reilly & Associates, Inc., 1991. ISBN
0-937175-75-7
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ System Administrator's Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0109-0
+ P3300E.
+ Programmers' GuidesAsente, Paul. X Window System
Toolkit. Digital Press. ISBN
1-55558-051-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-078-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary
Documents. O'Reilly & Associates, Inc., 1994.
ISBN 1-56592-079-1Harbison, Samuel P. and Steele, Guy L. Jr. C: A
Reference Manual. 4rd ed. Prentice Hall, 1995.
ISBN 0-13-326224-3Kernighan, Brian and Dennis M. Ritchie. The C
Programming Language.. PTR Prentice Hall, 1988.
ISBN 0-13-110362-9Lehey, Greg. Porting UNIX Software.
O'Reilly & Associates, Inc., 1995. ISBN
1-56592-126-7Plauger, P. J. The Standard C
Library. Prentice Hall, 1992. ISBN
0-13-131509-9Stevens, W. Richard. Advanced Programming in the
UNIX Environment. Reading, Mass. :
Addison-Wesley, 1992 ISBN 0-201-56317-7Stevens, W. Richard. UNIX Network
Programming. 2nd Ed, PTR Prentice Hall, 1998. ISBN
0-13-490012-XWells, Bill. “Writing Serial Drivers for UNIX”.
Dr. Dobb's Journal. 19(15), December
1994. pp68-71, 97-99.Operating System InternalsAndleigh, Prabhat K. UNIX System
Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5Jolitz, William. “Porting UNIX to the
386”. Dr.
Dobb's Journal. January 1991-July 1992.Leffler, Samuel J., Marshall Kirk McKusick, Michael J
Karels and John Quarterman The Design and
Implementation of the 4.3BSD UNIX Operating
System. Reading, Mass. : Addison-Wesley,
1989. ISBN 0-201-06196-1Leffler, Samuel J., Marshall Kirk McKusick, The
Design and Implementation of the 4.3BSD UNIX Operating
System: Answer Book. Reading, Mass. :
Addison-Wesley, 1991. ISBN 0-201-54629-9McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation
of the 4.4BSD Operating System. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-54979-4Stevens, W. Richard. TCP/IP Illustrated, Volume
1: The Protocols. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-63346-9Schimmel, Curt. Unix Systems for Modern
Architectures. Reading, Mass. : Addison-Wesley,
1994. ISBN 0-201-63338-8Stevens, W. Richard. TCP/IP Illustrated, Volume
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
Protocols. Reading, Mass. : Addison-Wesley,
1996. ISBN 0-201-63495-3Vahalia, Uresh. UNIX Internals -- The New
Frontiers. Prentice Hall, 1996. ISBN
0-13-101908-2Wright, Gary R. and W. Richard Stevens. TCP/IP
Illustrated, Volume 2: The Implementation.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63354-XSecurity ReferenceCheswick, William R. and Steven M. Bellovin.
Firewalls and Internet Security: Repelling the Wily
Hacker. Reading, Mass. : Addison-Wesley,
1995. ISBN 0-201-63357-4Garfinkel, Simson and Gene Spafford. Practical
UNIX Security. 2nd Ed. O'Reilly & Associates,
Inc., 1996. ISBN 1-56592-148-8Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995.
ISBN 1-56592-098-8Hardware ReferenceAnderson, Don and Tom Shanley. Pentium Processor
System Architecture. 2nd Ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40992-5Ferraro, Richard F. Programmer's Guide to the
EGA, VGA, and Super VGA Cards. 3rd ed. Reading,
Mass. : Addison-Wesley, 1995. ISBN
0-201-62490-7Intel Corporation publishes documentation on their CPUs,
chipsets and standards on their developer web site,
usually as PDF files.Shanley, Tom. 80486 System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40994-1Shanley, Tom. ISA System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40996-8Shanley, Tom. PCI System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40993-3Van Gilluwe, Frank. The Undocumented
PC. Reading, Mass: Addison-Wesley Pub. Co.,
1994. ISBN 0-201-62277-7UNIX HistoryLion, John Lion's Commentary on UNIX, 6th Ed.
With Source Code. ITP Media Group, 1996. ISBN 1573980137Raymond, Eric s. The New Hacker's Dictonary, 3rd
edition. MIT Press, 1996. ISBN
0-262-68092-0 Also known as the Jargon
FileSalus, Peter H. A quarter century of
UNIX. Addison-Wesley Publishing Company, Inc.,
1994. ISBN 0-201-54777-5Simon Garfinkel, Daniel Weise, Steven Strassmann.
The UNIX-HATERS Handbook. IDG Books
Worldwide, Inc., 1994. ISBN 1-56884-203-1Don Libes, Sandy Ressler Life with
UNIX — special edition. Prentice-Hall, Inc.,
1989. ISBN 0-13-536657-7The BSD family tree. 1997. ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree or local on a FreeBSD-current machine.The BSD Release Announcements
collection. 1997. http://www.de.FreeBSD.ORG/de/ftp/releases/Networked Computer Science Technical Reports
Library. http://www.ncstrl.org/Old BSD releases from the Computer Systems Research
group (CSRG). http://www.mckusick.com/csrg/: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last disk holds the final sources plus the SCCS files.Magazines and JournalsThe C/C++ Users Journal. R&D
Publications Inc. ISSN 1075-2838Sys Admin — The Journal for UNIX System
Administrators Miller Freeman, Inc., ISSN
1061-2688
diff --git a/en/handbook/contrib/chapter.sgml b/en/handbook/contrib/chapter.sgml
index 2dffa913a2..bd3723e510 100644
--- a/en/handbook/contrib/chapter.sgml
+++ b/en/handbook/contrib/chapter.sgml
@@ -1,2895 +1,2954 @@
Contributing to FreeBSDContributed by &a.jkh;.So you want to contribute something to FreeBSD? That is great! We
can always use the help, and FreeBSD is one of those systems that
relies on the contributions of its user base in
order to survive. Your contributions are not only appreciated, they
are vital to FreeBSD's continued growth!Contrary to what some people might also have you believe, you do
not need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help
the project!Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product?
Please let us know! We may be able to work cooperatively on some
aspect of it. The free software world is challenging a lot of
existing assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at least give
it a second look.What Is NeededThe following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user
requests we have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If you are
interested in working on one of the tasks you see here, send mail to
the coordinator listed by clicking on their names. If no
coordinator has been appointed, maybe you would like to
volunteer?High priority tasksThe following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:3-stage boot issues. Overall coordination:
&a.hackers;Move userconfig (-c) into 3rd stage boot.Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.Filesystem problems. Overall coordination: &a.fs;Fix the MSDOS file system.Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;Fix the union file system. Coordinator:
&a.dg;Implement kernel and user vm86 support. Coordinator:
&a.jlemon;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;Kernel issues. Overall coordination: &a.hackers;Complete the eisaconf conversion of all existing
drivers.Change all interrupt routines to take a (void *)
instead of using unit numbers.Merge EISA/PCI/ISA interrupt registration
code.Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).Medium priority tasksThe following tasks need to be done, but not with any
particular urgency:Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth Jones ajones@ctron.comMCA support? This should be finalized one way or the
other.Full LKM based driver support/Configuration Manager.Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;Documentation!Reliable operation of the pcic driver (needs
testing).Recognizer and handler for
sio.c (mostly done).Recognizer and handler for
ed.c (mostly done).Recognizer and handler for
ep.c (mostly done).User-mode recognizer and handler (partially
done).Advanced Power Management. Coordinators: &a.msmith; and
&a.phk;APM sub-driver (mostly done).IDE/ATA disk sub-driver (partially done).syscons/pcvt sub-driver.Integration with the PCMCIA/PCCARD drivers
(suspend/resume).Low priority tasksThe following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them
done anytime soon:The first 20 items are from Terry Lambert
terry@lambert.orgAbility to make BIOS calls from protected mode using V86
mode on the processor and return the results via a mapped
interrupt IPC mechanism to the protected mode caller.Drivers built into the kernel that use the BIOS call
mechanism to allow them to be independent of the actual
underlying hardware the same way that DOS is independent of
the underlying hardware. This includes NetWork and ASPI
drivers loaded in DOS prior to BSD being loaded by a
DOS-based loader program, which means potential polling,
which means DOS-not-busy interrupt generation for V86
machines by the protected mode kernel.An image format that allows tagging of such drivers data
and text areas in the default kernel executable so that that
portion of the kernel address space may be recovered at a
later time, after hardware specific protected mode drivers
have been loaded and activated. This includes separation of
BIOS based drivers from each other, since it is better to
run with a BIOS based driver in all cases than to not run at
all.Abstraction of the bus interface mechanism. Currently,
PCMCIA, EISA, and PCI busses are assumed to be bridged from
ISA. This is not something which should be assumed.A configuration manager that knows about PNP events,
including power management events, insertion, extraction,
and bus (PNP ISA and PCMCIA bridging chips) vs. card level
event management.A topological sort mechanism for assigning reassignable
addresses that do not collide with other reassignable and
non-reassignable device space resource usage by fixed
devices.A registration based mechanism for hardware services
registration. Specifically, a device centric registration
mechanism for timer and sound and other system critical
service providers. Consider Timer2 and Timer0 and speaker
services as one example of a single monolithic service
provider.A kernel exported symbol space in the kernel data space
accessible by an LKM loader mechanism that does relocation
and symbol space manipulation. The intent of this interface
is to support the ability to demand load and unload kernel
modules.NetWare Server (protected mode ODI driver) loader and
subservices to allow the use of ODI card drivers supplied
with network cards. The same thing for NDIS drivers and
NetWare SCSI drivers.An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.Splitting of the console driver into abstraction layers,
both to make it easier to port and to kill the X and
ThinkPad and PS/2 mouse and LED and console switching and
bouncing NumLock problems once and for all.Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.Streams to allow the use of commercial streams drivers.Kernel multithreading (requires kernel preemption).Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).A concerted effort at support for portable computers.
This is somewhat handled by changing PCMCIA bridging rules
and power management event handling. But there are things
like detecting internal vs. external display and picking a
different screen resolution based on that fact, not spinning
down the disk if the machine is in dock, and allowing
dock-based cards to disappear without affecting the machines
ability to boot (same issue for PCMCIA).Reorganization of the source tree for multiple platform
ports.A make world that "makes the world" (rename the
current one to make regress if that is all it is good
for).A 4M (preferably smaller!) memory footprint.Smaller tasksMost of the tasks listed in the previous sections require
either a considerable investment of time or an in-depth knowledge
of the FreeBSD kernel (or both). However, there are also many
useful tasks which are suitable for "weekend hackers",
or people without programming skills.If you run FreeBSD-current and have a good Internet
connection, there is a machine current.freebsd.org which
builds a full release once a day — every now and again, try
and install the latest release from it and report any
failures in the process.Read the freebsd-bugs mailing list. There might be a
problem you can comment constructively on or with patches
you can test. Or you could even try to fix one of the
problems yourself.Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even just
completely wrong, let us know. Even better, send us a fix
(SGML is not difficult to learn, but there is no objection
to ASCII submissions).Help translate FreeBSD documentation into your native
language (if not already available) — just send an email to
&a.doc; asking if anyone is working on it. Note that you
are not committing yourself to translating every single
FreeBSD document by doing this — in fact, the documentation
most in need of translation is the installation
instructions.Read the freebsd-questions mailing list and the
newsgroup comp.unix.bsd.freebsd.misc occasionally (or even
regularly). It can be very satisfying to share your
expertise and help people solve their problems; sometimes
you may even learn something new yourself! These forums can
also be a source of ideas for things to work on.If you know of any bugfixes which have been successfully
applied to -current but have not been merged into -stable
after a decent interval (normally a couple of weeks), send
the committer a polite reminder.Move contributed software to
src/contrib in the source tree.Make sure code in src/contrib is up
to date.Look for year 2000 bugs (and fix any you find!)Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.If you have contributed any ports, send your patches
back to the original author (this will make your life easier
when they bring out the next version)Suggest further tasks for this list!How to ContributeContributions to the system generally fall into one or more of
the following 6 categories:Bug reports and general commentaryAn idea or suggestion of general
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
high volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
mailing lists for more
information about this and other mailing lists.If you find a bug or are submitting a specific change, please
report it using the send-pr1program or its
WEB-based
equivalent. Try to fill-in each field of the bug report.
Unless they exceed 65KB, include any patches directly in the
report. Consider compressing them and using
uuencode1 if they exceed 20KB. Upload very large submissions to ftp.freebsd.org:/pub/FreeBSD/incoming/.After filing a report, you should receive confirmation along
with a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to bug-followup@FreeBSD.ORG. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way.If you do not receive confirmation in a timely fashion (3 days
to a week, depending on your email connection) or are, for some
reason, unable to use the send-pr1 command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.Changes to the documentationChanges to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
send-pr as described in
Bug Reports and General
Commentary.Changes to existing source codeAn addition or change to the existing source code is a
somewhat trickier affair and depends a lot on how far out of date
you are with the current state of the core FreeBSD development.
There is a special on-going release of FreeBSD known as
“FreeBSD-current” which is made available in a variety of ways
for the convenience of developers working actively on the system.
See Staying current with FreeBSD
for more information
about getting and using FreeBSD-current.Working from older sources unfortunately means that your
changes may sometimes be too obsolete or too divergent for easy
re-integration into FreeBSD. Chances of this can be minimized
somewhat by subscribing to the &a.announce; and the &a.current;
lists, where discussions on the current state of the system take
place.Assuming that you can manage to secure fairly up-to-date
sources to base your changes on, the next step is to produce a set
of diffs to send to the FreeBSD maintainers. This is done with
the diff1 command, with the “context diff”
form being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; diff -c -r olddir newdir
would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for diff1 for more details.Once you have a set of diffs (which you may test with the
patch1 command), you should submit them for
inclusion with FreeBSD. Use the send-pr1
program as described in
Bug Reports and General
Commentary. Do not just send the diffs to
the &a.hackers; or they will get lost! We greatly appreciate your
submission (this is a volunteer project!); because we are busy, we
may not be able to address it immediately, but it will remain in
the pr database until we do.If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file and run the
uuencode1 program on it. Shar archives are
also welcome.If your change is of a potentially sensitive nature, e.g. you
are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review
first, then you should send it to &a.core; directly rather than
submitting it with send-pr1. The core
mailing list reaches a much smaller group of people who do much of
the day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to
them where it is truly necessary.Please refer to man 9 intro and
man 9 style for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.New code or major value-added packagesIn the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD, it
becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:The BSD copyright. This copyright is most preferred due
to its “no strings attached” nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial
interests who might eventually be inclined to invest
something of their own into FreeBSD.The GNU Public License, or “GPL”. This license is not
quite as popular with us due to the amount of extra effort
demanded of anyone using the code for commercial purposes,
but given the sheer quantity of GPL'd code we currently
require (compiler, assembler, text formatter, etc) it would
be silly to refuse additional contributions under this
license. Code under the GPL also goes into a different part
of the tree, that being /sys/gnu or
/usr/src/gnu, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will be
considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.To place a “BSD-style” copyright on your work, include the
following text at the very beginning of every source code file you
wish to protect, replacing the text between the
%% with the appropriate information.
Copyright (c) %%proper_years_here%%
%%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$For your convenience, a copy of this text can
be found in
/usr/share/examples/etc/bsd-style-copyright.Money, Hardware or Internet accessWe are always very happy to accept donations to further the
cause of the FreeBSD Project and, in a volunteer effort like ours,
a little can go a long way! Donations of hardware are also very
important to expanding our list of supported peripherals since we
generally lack the funds to buy such items ourselves.Donating fundsWhile the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.dg; with the goal of furthering the aims of the FreeBSD
Project and giving it a minimal corporate presence. Any and all
funds donated (as well as any profits that may eventually be
realized by FreeBSD, Inc.) will be used exclusively to further
the project's goals.Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:FreeBSD, Inc.c/o Jordan Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO
box can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to
Jordan Hubbard jkh@FreeBSD.org,
either via email or to the FreeBSD, Inc. postal address given
above.If you do not wish to be listed in our donors section, please specify this
when making your donation. Thanks!Donating hardwareDonations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the donating funds
section.Hardware for which ongoing compliance testing is
desired. We are currently trying to put together a testing
lab of all components that FreeBSD supports so that proper
regression testing can be done with each new release. We
are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a
donation, please contact &a.dg; for information on
which items are still required.Hardware currently unsupported by FreeBSD for which
you would like to see such support added. Please contact
the &a.core; before sending such items as we will need to
find a developer willing to take on the task before we can
accept delivery of new hardware.Donating Internet accessWe can always use new mirror sites for FTP, WWW or cvsup. If
you would like to be such a mirror, please contact the FreeBSD project
administrators admin@FreeBSD.ORG for more information.Donors GalleryThe FreeBSD Project is indebted to the following donors and
would like to publically thank them here!Contributors to the central server
project:The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
freefall.freebsd.org by donating the
following items:Ade
Barkah mbarkah@freebsd.org and his employer, Hemisphere Online,
donated a Pentium Pro (P6) 200Mhz
CPUASA
Computers donated a Tyan
1662 motherboard.Joe McGuckin joe@via.net
of ViaNet
Communications donated a Kingston ethernet controller.Jack
O'Neill jack@diamond.xtalwind.net donated an NCR
53C875 SCSI controller card.Ulf
Zimmermann ulf@Alameda.net of Alameda Networks
donated 128MB of memory, a
4 Gb disk drive and the
case.Direct funding:The following individuals and businesses have generously
contributed direct funding to the project:Annelise
Anderson ANDRSN@HOOVER.STANFORD.EDUMatt
Dillon dillon@best.netEpilogue
Technology CorporationSean Eric FaganDon Scott WildeGianmarco
Giovannelli gmarco@masternet.itJosef C.
Grosch joeg@truenorth.orgRobert T. MorrisChuck
Robey chuckr@freebsd.orgKenneth
P. Stox ken@stox.sa.enteract.com of Imaginary Landscape,
LLC.Dmitry S.
Kohmanyuk dk@dog.farm.orgLaser5
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.Fuki
Shuppan Publishing Co. donated a portion of
their profits from Hajimete no
FreeBSD (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.ASCII
Corp. donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.Yokogawa
Electric Corp has generously donated
significant funding to the FreeBSD project.BuffNET
+
+ Pacific
+ Solutions
+ Hardware contributors:The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:Walnut Creek CDROM for providing the Pentium P5-90
and 486/DX2-66 EISA/VL systems that are being used for
our development work, to say nothing of the network
access and other donations of hardware resources.TRW Financial Systems, Inc. provided 130 PCs, three
68 GB fileservers, twelve Ethernets, two routers and an
ATM switch for debugging the diskless code. They also
keep a couple of FreeBSD hackers alive and busy.
Thanks!Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.&a.chuck; contributed his floppy tape streamer for
experimental work.Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver.Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-)Tekram
Technologies sent one each of their DC-390,
DC-390U and DC-390F FAST and ULTRA SCSI host adapter
cards for regression testing of the NCR and AMD drivers
with their cards. They are also to be applauded for
making driver sources for free operating systems
available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD.Larry M.
Augustin contributed not only a Symbios
Sym8751S SCSI card, but also a set of data books,
including one about the forthcoming Sym53c895 chip with
Ultra-2 and LVD support, and the latest programming
manual with information on how to safely use the
advanced features of the latest Symbios SCSI chips.
Thanks a lot!Christoph
Kukulies kuku@freebsd.org donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.Special contributors:Walnut Creek
CDROM has donated almost more than we can say
(see the
history document for
more details). In particular, we would like to thank
them for the original hardware used for
freefall.FreeBSD.ORG, our primary
development machine, and for
thud.FreeBSD.ORG, a testing and
build box. We are also indebted to them for funding
various contributors over the years and providing us
with unrestricted use of their T1 connection to the
Internet.The interface
business GmbH, Dresden has been patiently
supporting &a.joerg; who has often preferred FreeBSD
work over paywork, and used to fall back to their (quite
expensive) EUnet Internet connection whenever his
private connection became too slow or flakey to work
with it...Berkeley Software
Design, Inc. has contributed their DOS
emulator code to the remaining BSD world, which is used
in the dosemu command.Derived Software ContributorsThis software was originally derived from William F. Jolitz's
386BSD release 0.1, though almost none of the original 386BSD
specific code remains. This software has been essentially
re-implemented from the 4.4BSD-Lite release provided by the Computer
Science Research Group (CSRG) at the University of California,
Berkeley and associated academic contributors.There are also portions of NetBSD and OpenBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAda T Lim ada@bsd.orgAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian T. Filipi-Martin atf3r@agate.cs.virginia.eduAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker A.C.P.M.Kalker@student.utwente.nlAlan Cox alc@cs.rice.eduAmancio Hasty ahasty@freebsd.orgAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndrew Gallatin gallatin@cs.duke.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew McRae amcrae@cisco.comAndrew Moore alm@FreeBSD.orgAndrew Stevenson andrew@ugh.net.auAndrew V. Stesin stesin@elvisti.kiev.uaAndrey Zakhvatov andy@icc.surw.chel.suAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.com
-
+
+
+ Anton Berezin tobez@plab.ku.dk
+
+
Ari Suutari ari@suutari.iki.fiBen Hutchinson benhutch@xfiles.org.ukBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBrandon Gillespie brandon@roguetrader.com&a.wlloyd;Bob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Taylor brett@peloton.physics.montana.eduBrian Clapper bmc@willscreek.com
-
+
+
+ Brian F. Feldman green@unixhelp.org
+
+
Brian Handy handy@lambic.space.lockheed.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce Gingery bgingery@gtcs.comBruce Mah bmah@ca.sandia.govCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCharles Hannum mycroft@ai.mit.eduCharles Mott cmott@srv.netChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChris Dabrowski chris@vader.orgChris G. Demetriou cgd@postgres.berkeley.eduChris Shenton cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristoph Robitschko chmr@edvz.tu-graz.ac.atChristopher T. Johnson
cjohnson@neunacht.netgsi.comChoi Jun Ho junker@jazz.snu.ac.krChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGConrad Sabatier conrads@neosoft.comCornelis van der Laan nils@guru.ims.uni-stuttgart.deCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comDai Ishijima ishijima@tri.pref.osaka.jpDan Cross tenser@spitfire.ecsel.psu.eduDaniel Baker dbaker@crash.ops.neosoft.comDaniel M. Eischen deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDanny J. Zerkel dzerkel@feephi.phofarm.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Edmondson davided@sco.comDave Rivers rivers@ponds.uucpDavid A. Bader dbader@umiacs.umd.eduDavid Dawes dawes@physics.su.OZ.AUDavid Holloway daveh@gwythaint.tamis.comDavid Leonard d@scry.dstc.edu.auDean Huxley dean@fsa.ca
-
+
+
+ Dima Sivachenko demon@gpad.ac.ru
+
+
Dirk Froemberg dirk@hal.in-berlin.deDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Yuniskis dgy@rtd.comDonald Maddox dmaddox@scsn.netDoug Ambrisko ambrisko@ambrisko.roble.comDouglas Carmichael dcarmich@mcs.comEckart “Isegrim” Hofmann
Isegrim@Wunder-Nett.orgEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Chet ejc@bazzle.comEric J. Schwertfeger eric@cybernut.comFrancis M J Hsieh mjhsieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan frankch@waru.life.nthu.edu.twFrank Maclachlan fpm@crash.cts.comFrank Nobis fn@trinity.radio-do.deFrank Volf volf@oasis.IAEhv.nlFUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jpFURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jpGary A. Browning gab10@griffcd.amdahl.comGary Kline kline@thought.orgGerard Roudier groudier@club-internet.frGilad Rom rom_glsa@ein-hashofet.co.ukGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGlenn Johnson gljohns@bellsouth.netGreg Ungerer gerg@stallion.oz.auHans Huebner hans@artcom.deHans Petter Bieker hanspb@persbraten.vgs.noHarlan Stenn Harlan.Stenn@pfcs.comHavard Eidnes Havard.Eidnes@runit.sintef.noHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jp
-
- Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
-
-
Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+
+
Hironori Ikura hikura@kaisei.orgHiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jpHolger Veit Holger.Veit@gmd.deHONDA Yasuhiro honda@kashio.info.mie-u.ac.jpHorance Chou horance@freedom.ie.cycu.edu.twHung-Chi Chu hcchu@r350.ee.ntu.edu.twIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jpIshii MasahiroIseei Suzuki issei@jp.FreeBSD.ORGItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. David Lowe lowe@saturn5.comJ. Han jtc@cygnus.comJ.T. Conklin jtc@cygnus.comJ.T. Lang keith@email.gcn.net.twJames Clark jjc@jclark.comJames da Silva jds@cs.umd.edu et alJanusz Kokot janek@gaja.ipan.lublin.plJason Thorpe thorpej@nas.nasa.govJavier Martin Rueda jmrueda@diatel.upm.esJeff Bartig jeffb@doit.wisc.eduKeff Kletsky Jeff@Wagsky.comJeffrey Wheat jeff@cetlink.netJeremy Lea reg@shale.csir.co.zaJerry Hicks jhicks@glenatl.glenayre.comJian-Da Li jdli@csie.NCTU.edu.twJim Binkley jrb@cs.pdx.eduJim Lowe james@cs.uwm.edu
-
+
+
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld/orgJoao Carlos Mendes Luis jonny@coppe.ufrj.br
+
+ Joe Abley jabley@clear.co.nz
+
+
Joe “Marcus” Clarke
marcus@miami.eduJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoel Sutton sutton@aardvark.apana.org.auJohann Tonsing jtonsing@mikom.csir.co.zaJohn Capo jc@irbs.comJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Perry perry@vishnu.alias.netJohn Polstra jdp@polstra.comJohn Rochester jr@cs.mun.caJohn Saunders john@pacer.nlc.net.auJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJosef Karthauser joe@uk.freebsd.orgJoseph Stein joes@seaport.netJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJulian Assange proff@suburbia.netJulian Jenkins kaveman@magna.com.auJulian Stacey jhs@freebsd.orgJunichi Satoh junichi@jp.freebsd.orgJunya WATANABE junya-w@remus.dti.ne.jpKapil Chowksey kchowksey@hss.hns.comKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKeith Bostic bostic@bostic.comKeith MooreKenneth Monville desmo@bandwidth.orgKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKirk McKusick mckusick@mckusick.comKiroh HARADA kiroh@kh.rim.or.jpKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.su
-
+
+
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+
+
Kurt Olsen kurto@tiny.mcs.usu.eduLars Köller Lars.Koeller@Uni-Bielefeld.DELian Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twuLucas James Lucas.James@ldjpc.apana.org.auLuigi Rizzo luigi@iet.unipi.it
-
+
+
+ Malte Lance malte.lance@gmx.net
+
+
Makoto MATSUSHITA matusita@jp.freebsd.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jp
+
+
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ Manu Iyengar iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMario Sergio Fujikawa Ferreira lioux@gns.com.brMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin BirgmeierMartti Kuparinen erakupa@kk.etx.ericsson.seMasachika ISHIZUKA ishizuka@isis.min.ntt.jpMasanori Kiriake seiken@ncs.co.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas thomas@lkg.dec.comMatt White mwhite+@CMU.EDUMatthew N. Dodd winter@jurai.netMatthew Stein matt@bdd.netMaurice Castro maurice@planet.serc.rmit.edu.auMichael Butschky butsch@computi.erols.comMichael Elbel me@FreeBSD.ORGMichael Searle searle@longacre.demon.co.ukMiguel Angel Sagreras msagre@cactus.fi.uba.arMikael Hybsch micke@dynas.seMikhail Teterin mi@aldan.ziplink.netMike McGaughey mmcg@cs.monash.edu.auMike Peck mike@binghamton.eduMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMITA Yoshio mita@jp.FreeBSD.ORGMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMotoyuki Kasahara m-hasahr@sra.co.jp
+
+
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.comNAKAMURA Kazushi nkazushi@highway.or.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNIIMI Satoshi sa2c@and.or.jpNick Sayer nsayer@quack.kfu.comNicolas Souchu Nicolas.Souchu@prism.uvsq.frNisha Talagala nisha@cs.berkeley.eduNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
+
+
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+
+
Noritaka Ishizumi graphite@jp.FreeBSD.ORGOliver Breuninger ob@seicom.NETOliver Fromme oliver.fromme@heim3.tu-clausthal.deOliver Laumann net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.com
-
+
+
+ Palle Girgensohn girgen@partitur.se
+
+
Paul Fox pgf@foxharp.boston.ma.usPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaulo Menezes paulo@isr.uc.ptPaul T. Root proot@horton.iaces.comPedro Giffuni giffunip@asme.orgPedro A M Vazquez vazquez@IQM.Unicamp.BRPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Stubbs PETERS@staidan.qld.edu.auPierre Beyssac bp@fasterix.freenix.orgPhil Maker pjm@cs.ntu.edu.auR. Kym HorsellRandall Hopper rhh@stealth.ct.picker.comRicardas Cepas rch@richard.eu.orgRichard Hwang rhwang@bigpanda.comRichard. M. Neswold rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Wiwatowski rjwiwat@adelaide.on.netRob Mallory rmallory@csusb.eduRob Shady rls@id.netRob Snow rsnow@txdirect.netRobert Sanders rsanders@mindspring.comRobert Withrow witr@rwwa.comRonald Kuehn kuehn@rz.tu-clausthal.deRoland Jesse jesse@cs.uni-magdeburg.deRuslan Shevchenko rssh@cki.ipri.kiev.uaSURANYI Peter suranyip@jks.is.tsukuba.ac.jpSamuel Lam skl@ScalableNetwork.comSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+
+ Satsuki FUJISHIMA k5@respo.or.jp
+
+
Scot W. Hetzel hetzels@westbend.netScott Blachowicz scott.blachowicz@seaslug.orgScott A. Kenney saken@rmta.ml.orgSeigou TANIMURA
tanimura@naklab.dnj.ynu.ac.jp
-
- Seiichirou Hiraoka flathill@flathill.gr.jp
-
-
Serge Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSheldon Hearn axl@iafrica.comShigeyuki FUKUSHIMA
shige@kuis.kyoto-u.ac.jpSimon Marlow simonm@dcs.gla.ac.ukSlaven Rezic (Tomic) eserte@cs.tu-berlin.deSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan “Sec” Zehl sec@42.orgStephane Legrand stephane@lituus.frStephen Farrell stephen@farrell.orgStephen J. Roznowski sjr@home.netSteve Gerakines steve2@genesis.tiac.netSteven G. Kargl
kargl@troutmask.apl.washington.eduStephen H. Samorodin samorodi@NUXU.comStuart Henderson
stuart@internationalschool.co.uk
+
+
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeu NAIKI naiki@bfd.es.hokudai.ac.jpTed Faber faber@ISI.EDUTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo Deraadt deraadt@fsa.caThomas König Thomas.Koenig@ciw.uni-karlsruhe.deÞórður Ívarsson totii@est.isTim Kientzle kientzle@netcom.comTim Wilkinson tim@sarc.city.ac.uk
+
+ Tom Hukins tom@eborcom.com
+
+
Tom Jobbins tom@tom.tjTom Samplonius tom@misery.sdf.comTorbjorn Granlund tege@matematik.su.seToshihiro Kanda candy@fct.kgc.co.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpTrefor S. trefor@flevel.co.uk
-
+
+
+ Vadim Chekan vadim@gc.lviv.ua
+
+
Ville Eerola ve@sci.fiVladimir Kushnir kushn@mail.kar.netWerner Griessl werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWilko Bulte wilko@yedi.iaf.nlWolfgang Stanglmeier wolf@kintaro.cologne.deWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshiro Mihira sanpei@yy.cs.keio.ac.jp
- Yukihiro Nakai nakai@technologist.com
+ Yukihiro Nakai nakai@iname.comYusuke Nawano azuki@azkey.orgYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nl386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse lohse@tech7.informatik.uni-hamburg.deJörg Wunsch joerg_wunsch@uriah.heep.sax.deJohn Dyson formerly
dyson@ref.tfs.comJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@freebsd.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.ORGRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en/handbook/cutting-edge/chapter.sgml b/en/handbook/cutting-edge/chapter.sgml
index 93ceb6062b..f29687c694 100644
--- a/en/handbook/cutting-edge/chapter.sgml
+++ b/en/handbook/cutting-edge/chapter.sgml
@@ -1,2497 +1,2528 @@
The Cutting Edge: FreeBSD-current and FreeBSD-stableFreeBSD is under constant development between releases. For
people who want to be on the cutting edge, there are several easy
mechanisms for keeping your system in sync with the latest
developments. Be warned: the cutting edge is not for everyone! This
chapter will help you decide if you want to track the development
system, or stick with one of the released versions.Staying Current with FreeBSDContributed by &a.jkh;.What is FreeBSD-current?FreeBSD-current is, quite literally, nothing more than a daily
snapshot of the working sources for FreeBSD. These include work
in progress, experimental changes and transitional mechanisms that
may or may not be present in the next official release of the
software. While many of us compile almost daily from
FreeBSD-current sources, there are periods of time when the
sources are literally un-compilable. These problems are generally
resolved as expeditiously as possible, but whether or not
FreeBSD-current sources bring disaster or greatly desired
functionality can literally be a matter of which part of any given
24 hour period you grabbed them in!Who needs FreeBSD-current?FreeBSD-current is made generally available for 3 primary
interest groups:Members of the FreeBSD group who are actively working
on some part of the source tree and for whom keeping
“current” is an absolute requirement.Members of the FreeBSD group who are active testers,
willing to spend time working through problems in order to
ensure that FreeBSD-current remains as sane as possible.
These are also people who wish to make topical suggestions
on changes and the general direction of FreeBSD.Peripheral members of the FreeBSD (or some other)
group who merely wish to keep an eye on things and use the
current sources for reference purposes (e.g. for
reading, not running). These people
also make the occasional comment or contribute code.What is FreeBSD-current not?A fast-track to getting pre-release bits because you
heard there is some cool new feature in there and you want
to be the first on your block to have it.A quick way of getting bug fixes.In any way “officially supported” by us. We do our
best to help people genuinely in one of the 3 “legitimate”
FreeBSD-current categories, but we simply do not
have the time to provide tech support for it.
This is not because we are mean and nasty people who do not
like helping people out (we would not even be doing FreeBSD
if we were), it is literally because we cannot answer 400
messages a day and actually work on
FreeBSD! I am sure that, if given the choice between having
us answer lots of questions or continuing to improve
FreeBSD, most of you would vote for us improving it.Using FreeBSD-currentJoin the &a.current; and the &a.cvsall; . This is not
just a good idea, it is essential. If
you are not on the FreeBSD-current
- mailing list you will not see the comments that people are
+ mailing list, you will not see the comments that people are
making about the current state of the system and thus will
probably end up stumbling over a lot of problems that others
have already found and solved. Even more importantly, you
- will miss out on potentially critical information (e.g.
- “Yo, Everybody! Before you rebuild
- /usr/src, you must
- rebuild the kernel or your system will crash horribly!”).
- The cvs-all mailing list will allow you
+ will miss out on important bulletins which may be critical
+ to your system's continued health.
+
+ The cvs-all mailing list will allow you
to see the commit log entry for each change as it is made
along with any pertinent information on possible
- side-effects. To join these lists, send mail to
+ side-effects.
+
+ To join these lists, send mail to
&a.majordomo; and specify:
subscribe freebsd-current
subscribe cvs-all
in the
body of your message. Optionally, you can also say help
and Majordomo will send you full help on how to subscribe
and unsubscribe to the various other mailing lists we
support.Grab the sources from ftp.FreeBSD.ORG. You can do
this in three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile">this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
+
+
+ &prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz
+
+
+
Use ftp. The source tree for FreeBSD-current is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current We also use wu-ftpd which allows compressed/tar'd grabbing of whole trees. e.g. you see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the whole directory for you as a compressed tar file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.
-
-
-
+
If you are grabbing the sources to run, and not just
look at, then grab all of current, not
just selected portions. The reason for this is that various
parts of the source depend on updates elsewhere, and trying
to compile just a subset is almost guaranteed to get you
into trouble.
-
-
-
+
Before compiling current, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.current; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
- towards the next release.
+ towards the next release.
Be active! If you are running FreeBSD-current, we
want to know what you have to say about it, especially if
you have suggestions for enhancements or bug fixes.
Suggestions with accompanying code are received most
enthusiastically!Staying Stable with FreeBSDContributed by &a.jkh;.What is FreeBSD-stable?FreeBSD-stable is our development branch for a more low-key
and conservative set of changes intended for our next mainstream
release. Changes of an experimental or untested nature do not go
into this branch (see FreeBSD-current).Who needs FreeBSD-stable?If you are a commercial user or someone who puts maximum
stability of their FreeBSD system before all other concerns, you
should consider tracking stable. This is
especially true if you have installed the most recent release
(&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release.The stable tree endeavors, above all,
to be fully compilable and stable at all times, but we do
occasionally make mistakes (these are still active sources with
quickly-transmitted updates, after all). We also do our best to
thoroughly test fixes in current before
bringing them into stable, but sometimes
our tests fail to catch every case. If something breaks for you
in stable, please let us know
immediately! (see next section).Using FreeBSD-stableJoin the &a.stable; . This will keep you informed of
build-dependencies that may appear in
stable or any other issues requiring
special attention. Developers will also make announcements
in this mailing list when they are contemplating some
controversial fix or update, giving the users a chance to
respond if they have any issues to raise concerning the
- proposed change. To join this list, send mail to
- &a.majordomo; and say:
+ proposed change.
+
+ The cvs-all mailing list will allow you
+ to see the commit log entry for each change as it is made
+ along with any pertinent information on possible
+ side-effects.
+
+ To join these lists, send mail to
+ &a.majordomo; and specify:
-subscribe freebsd-stable In the body of your
- message. Optionally, you can also say help and Majordomo
- will send you full help on how to subscribe and unsubscribe
- to the various other mailing lists we support.
+subscribe freebsd-stable
+subscribe cvs-all
+
+ in the
+ body of your message. Optionally, you can also say help
+ and Majordomo will send you full help on how to subscribe
+ and unsubscribe to the various other mailing lists we
+ support.
If you are installing a new system and want it to be as stable
as possible, you can simply grab the latest dated branch snapshot
from ftp://releng22.freebsd.org/pub/FreeBSD/ and install it like any other release.If you are already running a previous release of 2.2 and wish
to upgrade via sources then you can easily do so from ftp.FreeBSD.ORG. This can be done in one of
three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type;&prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgzUse ftp. The source tree for FreeBSD-stable is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stableWe also use wu-ftpd which allows
compressed/tar'd grabbing of whole trees. e.g. you
see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the
whole directory for you as a compressed tar
file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.Before compiling stable, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.stable; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
towards the next release.Synchronizing Source Trees over the InternetContributed by &a.jkh;.There are various ways of using an Internet (or email)
connection to stay up-to-date with any given area of the FreeBSD
project sources, or all areas, depending on what interests you. The
primary services we offer are Anonymous
CVS, CVSup, and
CTM.Anonymous CVS and CVSup use the
pull model of updating sources. In the case of
CVSup the user (or a cron
script) invokes the cvsup program, and
it interacts with a cvsupd server
somewhere to bring your files up to date. The updates you receive
are up-to-the-minute and you get them when, and only when, you want
them. You can easily restrict your updates to the specific files or
directories that are of interest to you. Updates are generated on
the fly by the server, according to what you have and what you want
to have. Anonymous CVS is quite a bit more simplistic
than CVSup in that it's just an extension to
CVS which allows it to pull changes
directly from a remote CVS
repository. CVSup can do this far more
efficiently, but Anonymous CVS is easier to
use.CTM, on the other hand, does not
interactively compare the sources you have with those on the master
archive or otherwise pull them across.. Instead, a script which identifies changes in files since
its previous run is executed several times a day on the master CTM
machine,
any detected changes being compressed, stamped with a
sequence-number and encoded for transmission over email (in printable
ASCII only). Once received, these “CTM deltas” can then be handed
to the ctm_rmail1 utility which will automatically decode, verify
and apply the changes to the user's copy of the sources. This
process is far more efficient than CVSup, and places less strain on
our server resources since it is a push rather
than a pull model.There are other trade-offs, of course. If you inadvertently
wipe out portions of your archive, CVSup will detect and rebuild the
damaged portions for you. CTM won't do this, and if you wipe some
portion of your source tree out (and don't have it backed up) then
you will have to start from scratch (from the most recent CVS “base
delta”) and rebuild it all with CTM or, with anoncvs, simply
delete the bad bits and resync.For more information on Anonymous CVS, CTM, and CVSup, please see one of the
following sections:Anonymous CVSContributed by &a.jkh;IntroductionAnonymous CVS (or, as it is otherwise known,
anoncvs) is a feature provided by the CVS
utilities bundled with FreeBSD for synchronizing with a remote CVS
repository. Among other things, it allows users of FreeBSD to
perform, with no special privileges, read-only CVS operations
against one of the FreeBSD project's official anoncvs servers. To
use it, one simply sets the CVSROOT environment
variable to point at the appropriate anoncvs server and then uses
the cvs1 command to access it like any local
repository.While it can also be said that the CVSup and anoncvs
services both perform essentially the same function, there are
various trade-offs which can influence the user's choice of
synchronization methods. In a nutshell,
CVSup is much more efficient in its
usage of network resources and is by far the most technically
sophisticated of the two, but at a price. To use
CVSup, a special client must first be
installed and configured before any bits can be grabbed, and then
only in the fairly large chunks which
CVSup calls
collections.Anoncvs, by contrast, can be used
to examine anything from an individual file to a specific program
(like ls or grep) by
referencing the CVS module name. Of course,
anoncvs is also only good for read-only
operations on the CVS repository, so if it's your intention to
support local development in one repository shared with the
FreeBSD project bits then CVSup is
really your only option.Using Anonymous CVSConfiguring cvs1 to use an Anonymous CVS repository is a simple
matter of setting the CVSROOT environment variable
to point to one of the FreeBSD project's
anoncvs servers. At the time of this writing,
the following servers are available:USA:
anoncvs@anoncvs.freebsd.org:/cvsSince CVS allows one to “check out” virtually any
version of the FreeBSD sources that ever existed (or, in some
cases, will exist :), you need to be familiar with
the revision () flag to cvs1 and what some of the permissible values for it in
the FreeBSD Project repository are.There are two kinds of tags, revision tags and branch tags. A
revision tag refers to a specific revision. Its meaning stays the
same from day to day. A branch tag, on the other hand, refers to
the latest revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific revision,
it may mean something different tomorrow than it means
today.Here are the branch tags that users might be interested
in:HEADSymbolic name for the main line, or FreeBSD-current.
Also the default when no revision is
specified.
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
RELENG_2_2The line of development for FreeBSD-2.2.x, also known as
- FreeBSD-stable. Not valid for the ports collection.
+ 2.2-stable. Not valid for the ports collection.
RELENG_2_1_0The line of development for FreeBSD-2.1.x - this branch
is largely obsolete. Not valid for the ports
collection.Here are the revision tags that users might be interested
in:RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports
collection.RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports
collection.RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports
collection.RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports
collection.RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports
collection.RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports
collection.RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports
collection.RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports
collection.RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports
collection.RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports
collection.When you specify a branch tag, you normally receive the latest
versions of the files on that line of development. If you wish to
receive some past version, you can do so by specifying a date with
the flag. See the cvs1 man page for more details.ExamplesWhile it really is recommended that you read the manual page
for cvs1 thoroughly before doing
anything, here are some quick examples which essentially show how
to use Anonymous CVS:Checking out something from -current (ls1) and deleting it
again:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co ls
&prompt.user; cvs release -d lsChecking out the version of ls(1) in the 2.2-stable
branch:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co -rRELENG_2_2 ls
&prompt.user; cvs release -d lsCreating a list of changes (as unidiffs) to ls1 between FreeBSD 2.2.2
and FreeBSD 2.2.6:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE lsFinding out what other module names can be used:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co modules
&prompt.user; more modules/modules
&prompt.user; cvs release -d modulesOther ResourcesThe following additional resources may be helpful in learning
CVS:CVS Tutorial from Cal Poly.Cyclic
Software, commercial maintainers of CVS.CVSWeb
is the FreeBSD Project web interface for CVS.CTMContributed by &a.phk;. Updated
19-October-1997.CTM is a method for keeping a remote
directory tree in sync with a central one. It has been developed
for usage with FreeBSD's source trees, though other people may
find it useful for other purposes as time goes by. Little, if
any, documentation currently exists at this time on the process of
creating deltas, so talk to &a.phk; for more information should
you wish to use CTM for other things.Why should I use CTM?CTM will give you a local copy of the
FreeBSD source trees. There are a number of “flavors” of the
tree available. Whether you wish to track the entire cvs tree or
just one of the branches, CTM can provide you
the information. If you are an active developer on FreeBSD, but
have lousy or non-existent TCP/IP connectivity, or simply wish
to have the changes automatically sent to you,
CTM was made for you. You will need to obtain
up to three deltas per day for the most active branches.
However, you should consider having them sent by automatic
email. The sizes of the updates are always kept as small as
possible. This is typically less than 5K, with an occasional
(one in ten) being 10-50K and every now and then a biggie of
100K+ or more coming around.You will also need to make yourself aware of the various
caveats related to working directly from the development
sources rather than a pre-packaged release. This is particularly
true if you choose the “current” sources. It is recommended
that you read Staying current
with
FreeBSD.What do I need to use CTM?You will need two things: The CTM
program and the initial deltas to feed it (to get up to
“current” levels).The CTM program has been part of FreeBSD
ever since version 2.0 was released, and lives in
/usr/src/usr.sbin/CTM if
you have a copy of the source online.If you are running a pre-2.0 version of FreeBSD, you can
fetch the current CTM sources directly
from:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctmThe “deltas” you feed CTM can be had
two ways, FTP or e-mail. If you have general FTP access to the
Internet then the following FTP sites support access to
CTM:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTMor see section mirrors.FTP the relevant directory and fetch the
README file, starting from there.If you may wish to get your deltas via email:Send email to &a.majordomo; to subscribe to one of the
CTM distribution lists. “ctm-cvs-cur”
supports the entire cvs tree. “ctm-src-cur” supports the head
of the development branch. “ctm-src-2_2” supports the 2.2
release branch, etc. (If you do not know how to subscribe
yourself using majordomo, send a message first containing the
word help — it will send you back usage
instructions.)When you begin receiving your CTM updates
in the mail, you may use the ctm_rmail program
to unpack and apply them. You can actually use the
ctm_rmail program directly from a entry in
/etc/aliases if you want to have the
process run in a fully automated fashion. Check the
ctm_rmail man page for more details.No matter what method you use to get the
CTM deltas, you should subscribe to the
ctm-announce@FreeBSD.ORG mailing list. In the
future, this will be the only place where announcements
concerning the operations of the CTM system
will be posted. Send an email to &a.majordomo; with a single
line of subscribe
ctm-announce to get added to the list.Starting off with CTM for the first
timeBefore you can start using CTM deltas,
you will need to get a to a starting point for the deltas
produced subsequently to it.First you should determine what you already have. Everyone
can start from an “empty” directory. You must use an
initial “Empty&rdquo delta to start off your
CTM supported tree. At some point it is
intended that one of these “started” deltas be
distributed on the CD for your convenience. This does not
currently happen however.You can recognize
However, since the trees
are many tens of megabytes, you should prefer to start from
something already at hand. If you have a RELEASE CD, you can
copy or extract an initial source from it. This will save a
significant transfer of data.You can recognize these “starter” deltas by the
X appended to the number
(src-cur.3210XEmpty.gz for instance). The
designation following the X
corresponds to the origin of your initial “seed”. Empty is
an empty directory. As a rule a base transition from
Empty is produced
every 100 deltas. By the way, they are large! 25 to 30
Megabytes of gzip'ed data is
common for the XEmpty deltas.Once you've picked a base delta to start from, you will also
need all deltas with higher numbers following it.Using CTM in your daily lifeTo apply the deltas, simply say:&prompt.root; cd /where/ever/you/want/the/stuff
&prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.*CTM understands deltas which have been
put through gzip, so you do not
need to gunzip them first, this saves disk space.Unless it feels very secure about the entire process,
CTM will not touch your tree. To verify a
delta you can also use the flag and
CTM will not actually touch your tree; it
will merely verify the integrity of the delta and see if it
would apply cleanly to your current tree.There are other options to CTM as well,
see the manual pages or look in the sources for more
information.I would also be very happy if somebody could help with the
“user interface” portions, as I have realized that I cannot
make up my mind on what options should do what, how and
when...That's really all there is to it. Every time you get a new
delta, just run it through CTM to keep your
sources up to date.Do not remove the deltas if they are hard to download again.
You just might want to keep them around in case something bad
happens. Even if you only have floppy disks, consider using
fdwrite to make a copy.Keeping your local changesAs a developer one would like to experiment with and change
files in the source tree. CTM supports local modifications in a
limited way: before checking for the presence of a file
foo, it first looks for
foo.ctm. If this file exists, CTM will
operate on it instead of foo.This behaviour gives us a simple way to maintain local
changes: simply copy the files you plan to modify to the
corresponding file names with a .ctm
suffix. Then you can freely hack the code, while CTM keeps the
.ctm file up-to-date.Other interesting CTM optionsFinding out exactly what would be touched by an
updateYou can determine the list of changes that CTM will make
on your source repository using the
option to CTM.This is useful if you would like to keep logs of the
changes, pre- or post- process the modified files in any
manner, or just are feeling a tad paranoid :-).Making backups before updatingSometimes you may want to backup all the files that would
be changed by a CTM update.Specifying the option
causes CTM to backup all files that would be touched by a
given CTM delta to backup-file.Restricting the files touched by an updateSometimes you would be interested in restricting the scope
of a given CTM update, or may be interested in extracting just
a few files from a sequence of deltas.You can control the list of files that CTM would operate
on by specifying filtering regular expressions using the
and
options.For example, to extract an up-to-date copy of
lib/libc/Makefile from your collection of
saved CTM deltas, run the commands:&prompt.root; cd /where/ever/you/want/to/extract/it/
&prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*For every file specified in a CTM delta, the
and options
are applied in the order given on the command line. The file
is processed by CTM only if it is marked as eligible after all
the and
options are applied to it.Future plans for CTMTons of them:Use some kind of authentication into the CTM system,
so as to allow detection of spoofed CTM updates.Clean up the options to CTM, they
became confusing and counter intuitive.The bad news is that I am very busy, so any help in doing
this will be most welcome. And do not forget to tell me what
you want also...Miscellaneous stuffAll the “DES infected” (e.g. export controlled) source is
not included. You will get the “international” version only.
If sufficient interest appears, we will set up a sec-cur sequence too. There is a
sequence of deltas for the ports
collection too, but interest has not been all that high yet.
Tell me if you want an email list for that too and we will
consider setting it up.Thanks!&a.bde;for his pointed pen and invaluable comments.&a.sos;for patience.Stephen McKaywrote ctm_[rs]mail,
much appreciated.&a.jkh;for being so stubborn that I had to make it
better.All the usersI hope you like it...CVSupContributed by &a.jdp;.IntroductionCVSup is a software package for distributing and updating
source trees from a master CVS repository on a remote server
host. The FreeBSD sources are maintained in a CVS repository on
a central development machine in California. With CVSup,
FreeBSD users can easily keep their own source trees up to
date.CVSup uses the so-called pull model of
updating. Under the pull model, each client asks the server for
updates, if and when they are wanted. The server waits
passively for update requests from its clients. Thus all
updates are instigated by the client. The server never sends
unsolicited updates. Users must either run the CVSup client
manually to get an update, or they must set up a cron job to run
it automatically on a regular basis.The term CVSup, capitalized just so, refers to the entire
software package. Its main components are the client cvsup
which runs on each user's machine, and the server cvsupd which
runs at each of the FreeBSD mirror sites.As you read the FreeBSD documentation and mailing lists, you
may see references to sup. Sup was the
predecessor of CVSup, and it served a similar purpose. CVSup is
in used in much the same way as sup and, in fact, uses
configuration files which are backward-compatible with sup's.
Sup is no longer used in the FreeBSD project, because CVSup is
both faster and more flexible.InstallationThe easiest way to install CVSup if you are running FreeBSD
2.2 or later is to use either the port from the FreeBSD ports collection or the corresponding binary package, depending on whether you prefer to roll your own or not.If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately
cannot use the binary package versions due to the fact that it
requires a version of the C library that does not yet exist in
FreeBSD-2.1.{6,7}. You can easily use the port, however, just as with FreeBSD 2.2. Simply unpack the tar file, cd to the cvsup subdirectory and type make install.Because CVSup is written in Modula-3, both the package and the port require that the Modula-3 runtime libraries be installed. These are available as the lang/modula-3-lib port and the lang/modula-3-lib-3.6 package. If you follow the same directions as for cvsup, these libraries will be compiled and/or installed automatically when you install the CVSup port or package.The Modula-3 libraries are rather large, and fetching and
compiling them is not an instantaneous process. For that
reason, a third option is provided. You can get
statically linked FreeBSD executables for
CVSup from either the USA distribution site:ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup-bin-15.4.2.tar.gz (client including GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.4.2.tar.gz (client without GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupd-bin-15.4.2.tar.gz (server).as well as from the many FreeBSD FTP mirror sites around the
world.ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-15.3.tar.gz (client including GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.3.tar.gz (client without GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-15.3.tar.gz (server).Most users will need only the client. These executables are
entirely self-contained, and they will run on any version of
FreeBSD from FreeBSD-2.1.0 to FreeBSD-current.In summary, your options for installing CVSup are:FreeBSD-2.2 or later: static binary, port,
or packageFreeBSD-2.1.6, 2.1.7: static binary or
portFreeBSD-2.1.5 or earlier: static binaryConfigurationCVSup's operation is controlled by a configuration file
called the supfile. Beginning with
FreeBSD-2.2, there are some sample supfiles
in the directory /usr/share/examples/cvsup. These examples are also available from ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ if you are on a pre-2.2 system.The information in a supfile answers
the following questions for cvsup:Which files
do you want to receive?Which
versions of them do you want?Where do you
want to get them from?Where do you
want to put them on your own machine?Where do
you want to put your status files?In the following sections, we will construct a typical
supfile by answering each of these
questions in turn. First, we describe the overall structure of
a supfile.A supfile is a text file. Comments
begin with # and extend to the end of the line. Lines that
are blank and lines that contain only comments are
ignored.Each remaining line describes a set of files that the user
wishes to receive. The line begins with the name of a
“collection”, a logical grouping of files defined by the server.
The name of the collection tells the server which files you
want. After the collection name come zero or more fields,
separated by white space. These fields answer the questions
listed above. There are two types of fields: flag fields and
value fields. A flag field consists of a keyword standing
alone, e.g., delete or compress. A value field also begins
with a keyword, but the keyword is followed without intervening
white space by = and a second word. For example,
release=cvs is a value field.A supfile typically specifies more than
one collection to receive. One way to structure a
supfile is to specify all of the relevant
fields explicitly for each collection. However, that tends to
make the supfile lines quite long, and it
is inconvenient because most fields are the same for all of the
collections in a supfile. CVSup provides a
defaulting mechanism to avoid these problems. Lines beginning
with the special pseudo-collection name *default can be used
to set flags and values which will be used as defaults for the
subsequent collections in the supfile. A
default value can be overridden for an individual collection, by
specifying a different value with the collection itself.
Defaults can also be changed or augmented in mid-supfile by
additional *default lines.With this background, we will now proceed to construct a
supfile for receiving and updating the main
source tree of FreeBSD-current.Which files do you want to receive?The files available via CVSup are organized into named
groups called “collections”. The collections that are
available are described here. In this example, we wish to receive the
entire main source tree for the FreeBSD system. There is
a single large collection src-all which will give us all
of that, except the export-controlled cryptography
support. Let us assume for this example that we are in
the USA or Canada. Then we can get the cryptography code
with one additional collection, cvs-crypto. As a first
step toward constructing our supfile,
we simply list these collections, one per line:
src-all
cvs-cryptoWhich version(s) of them do you want?With CVSup, you can receive virtually any version of
the sources that ever existed. That is possible because
the cvsupd server works directly from the CVS repository,
which contains all of the versions. You specify which one
of them you want using the tag= and value
fields.Be very
careful to specify any tag= fields correctly. Some tags
are valid only for certain collections of files. If you
specify an incorrect or misspelled tag, CVSup will delete
files which you probably do not want deleted. In
particular, use only
tag=. for the ports-*
collections.The tag= field names a symbolic tag in the
repository. There are two kinds of tags, revision tags
and branch tags. A revision tag refers to a specific
revision. Its meaning stays the same from day to day. A
branch tag, on the other hand, refers to the latest
revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific
revision, it may mean something different tomorrow than it
means today.Here are the branch tags that users might be
interested in:tag=.The main line of development, also known as
FreeBSD-current.The . is not punctuation; it is the name
of the tag. Valid for all collections.
-
- tag=RELENG_2_2
-
-
- The line of development for FreeBSD-2.2.x,
- also known as FreeBSD-stable. Not valid for the
- ports-* collections.
-
-
-
-
+
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
+
+ RELENG_2_2
+
+
+ The line of development for FreeBSD-2.2.x, also known as
+ 2.2-stable. Not valid for the ports collection.
+
+
+
tag=RELENG_2_1_0The line of development for FreeBSD-2.1.x -
this branch is largely obsolete. Not valid for the
ports-* collections.Here are the revision tags that users might be
interested in:tag=RELENG_3_0_0_RELEASEFreeBSD-3.0. Not valid for the ports-*
collections.tag=RELENG_2_2_7_RELEASEFreeBSD-2.2.7. Not valid for the ports-*
collections.tag=RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports-*
collections.tag=RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports-*
collections.tag=RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports-*
collections.tag=RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports-*
collections.tag=RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports-*
collections.tag=RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports-*
collections.tag=RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports-*
collections.tag=RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports-*
collections.tag=RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports-*
collections.tag=RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports-*
collections.Be very
careful to type the tag name exactly as shown. CVSup
cannot distinguish between valid and invalid tags. If you
misspell the tag, CVSup will behave as though you had
specified a valid tag which happens to refer to no files
at all. It will delete your existing sources in that
case.When you specify a branch tag, you normally receive
the latest versions of the files on that line of
development. If you wish to receive some past version,
you can do so by specifying a date with the value
field. The cvsup1 manual page explains how to do
that.For our example, we wish to receive FreeBSD-current.
We add this line at the beginning of our
supfile:
*default tag=.There is an important special case that comes into
play if you specify neither a tag=
field nor a date=
field. In that case, you receive the actual RCS files
directly from the server's CVS repository, rather than
receiving a particular version. Developers generally
prefer this mode of operation. By maintaining a copy of
the repository itself on their systems, they gain the
ability to browse the revision histories and examine past
versions of files. This gain is achieved at a large cost
in terms of disk space, however.Where do you want to get them from?We use the host= field to tell cvsup where to obtain
its updates. Any of the CVSup
mirror sites will do, though you should try to select
one that's near to you. In this example, we'll use the
primary FreeBSD distribution site,
cvsup.FreeBSD.org:
*default host=cvsup.FreeBSD.orgOn any particular run of cvsup, you can override this
setting on the command line, with .Where do you want to put them on your own
machine?The prefix= field tells cvsup where to put the files
it receives. In this example, we will put the source files
directly into our main source tree, /usr/src. The src
directory is already implicit in the collections we have
chosen to receive, so this is the correct
specification:
*default prefix=/usrWhere should cvsup maintain its status files?The cvsup client maintains certain status files in
what is called the “base” directory. These files help
CVSup to work more efficiently, by keeping track of which
updates you have already received. We will use the
standard base directory, /usr/local/etc/cvsup:
*default base=/usr/local/etc/cvsupThis setting is used by default if it is not specified
in the supfile, so we actually do not
need the above line.If your base directory does not already exist, now
would be a good time to create it. The cvsup client will
refuse to run if the base directory does not exist.Miscellaneous supfile settings:There is one more line of boiler plate that normally
needs to be present in the supfile:
*default release=cvs delete use-rel-suffix compressrelease=cvs indicates that the server should get its
information out of the main FreeBSD CVS repository. This
is virtually always the case, but there are other
possibilities which are beyond the scope of this
discussion.delete gives CVSup permission to delete files. You
should always specify this, so that CVSup can keep your
source tree fully up to date. CVSup is careful to delete
only those files for which it is responsible. Any extra
files you happen to have will be left strictly
alone.use-rel-suffix is ... arcane. If you really want to
know about it, see the cvsup1 manual page. Otherwise,
just specify it and do not worry about it.compress enables the use of gzip-style compression
on the communication channel. If your network link is T1
speed or faster, you probably should not use compression.
Otherwise, it helps substantially.Putting it all together:Here is the entire supfile for
our example:
*default tag=.
*default host=cvsup.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress
src-all
cvs-cryptoRunning CVSupYou are now ready to try an update. The command line for
doing this is quite simple:&prompt.root; cvsup supfilewhere supfile is of course the name of the supfile you
have just created. Assuming you are running under X11, cvsup
will display a GUI window with some buttons to do the usual
things. Press the “go” button, and watch it run.Since you are updating your actual /usr/src tree in this
example, you will need to run the program as root so that cvsup
has the permissions it needs to update your files. Having just
created your configuration file, and having never used this
program before, that might understandably make you nervous.
There is an easy way to do a trial run without touching your
precious files. Just create an empty directory somewhere
convenient, and name it as an extra argument on the command
line:&prompt.root; mkdir /var/tmp/dest
&prompt.root; cvsup supfile /var/tmp/destThe directory you specify will be used as the destination
directory for all file updates. CVSup will examine your usual
files in /usr/src, but it will not modify
or delete any of them. Any file updates will instead land in
/var/tmp/dest/usr/src. CVSup will also
leave its base directory status files untouched when run this
way. The new versions of those files will be written into the
specified directory. As long as you have read access to
/usr/src, you do not even need to be root
to perform this kind of trial run.If you are not running X11 or if you just do not like GUIs,
you should add a couple of options to the command line when you
run cvsup:&prompt.root; cvsup -g -L 2 supfileThe tells cvsup not to use its GUI. This is automatic
if you are not running X11, but otherwise you have to specify
it.The tells cvsup to print out the details of all the
file updates it is doing. There are three levels of verbosity,
from to . The default is 0, which means total
silence except for error messages.There are plenty of other options available. For a brief
list of them, type cvsup -H. For more detailed descriptions,
see the manual page.Once you are satisfied with the way updates are working, you
can arrange for regular runs of cvsup using cron8. Obviously,
you should not let cvsup use its GUI when running it from
cron.CVSup File CollectionsThe file collections available via CVSup are organized
hierarchically. There are a few large collections, and they are
divided into smaller sub-collections. Receiving a large
collection is equivalent to receiving each of its
sub-collections. The hierarchical relationships among
collections are reflected by the use of indentation in the list
below.The most commonly used collections are src-all, cvs-crypto, and ports-all. The other collections are used
only by small groups of people for specialized purposes, and
some mirror sites may not carry all of them.cvs-all
release=cvsThe main FreeBSD CVS repository, excluding the
export-restricted cryptography code.distrib
release=cvsFiles related to the distribution and
mirroring of FreeBSD.doc-all
release=cvsSources for the FreeBSD handbook and other
documentation.ports-all
release=cvsThe FreeBSD ports collection.ports-archivers
release=cvsArchiving tools.ports-astro
release=cvsAstronomical ports.ports-audio
release=cvsSound support.ports-base
release=cvsMiscellaneous files at the top of
/usr/ports.ports-benchmarks
release=cvsBenchmarks.ports-biology
release=cvsBiology.ports-cad
release=cvsComputer aided design tools.ports-chinese
release=cvsChinese language support.ports-comms
release=cvsCommunication software.ports-converters
release=cvscharacter code converters.ports-databases
release=cvsDatabases.ports-deskutils
release=cvsThings that used to be on the desktop before
computers were invented.ports-devel
release=cvsDevelopment utilities.ports-editors
release=cvsEditors.ports-emulators
release=cvsEmulators for other operating
systems.ports-games
release=cvsGames.ports-german
release=cvsGerman language support.ports-graphics
release=cvsGraphics utilities.ports-japanese
release=cvsJapanese language support.ports-korean
release=cvsKorean language support.ports-lang
release=cvsProgramming languages.ports-mail
release=cvsMail software.ports-math
release=cvsNumerical computation
software.ports-mbone
release=cvsMBone applications.ports-misc
release=cvsMiscellaneous utilities.ports-net
release=cvsNetworking software.ports-news
release=cvsUSENET news software.ports-plan9
release=cvsVarious programs from Plan9.ports-print
release=cvsPrinting software.ports-russian
release=cvsRussian language support.ports-security
release=cvsSecurity utilities.ports-shells
release=cvsCommand line shells.ports-sysutils
release=cvsSystem utilities.ports-textproc
release=cvstext processing utilities (does not
include desktop publishing).ports-vietnamese
release=cvsVietnamese language support.ports-www
release=cvsSoftware related to the World Wide
Web.ports-x11
release=cvsPorts to support the X window
system.ports-x11-clocks
release=cvsX11 clocks.ports-x11-fm
release=cvsX11 file managers.ports-x11-fonts
release=cvsX11 fonts and font utilities.ports-x11-toolkits
release=cvsX11 toolkits.ports-x11-wmX11 window managers.src-all
release=cvsThe main FreeBSD sources, excluding the
export-restricted cryptography code.src-base
release=cvsMiscellaneous files at the top of
/usr/src.src-bin
release=cvsUser utilities that may be needed in
single-user mode
(/usr/src/bin).src-contrib
release=cvsUtilities and libraries from outside
the FreeBSD project, used relatively
unmodified
(/usr/src/contrib).src-etc
release=cvsSystem configuration files
(/usr/src/etc).src-games
release=cvsGames
(/usr/src/games).src-gnu
release=cvsUtilities covered by the GNU Public
License
(/usr/src/gnu).src-include
release=cvsHeader files
(/usr/src/include).src-kerberosIV
release=cvsKerberosIV security package
(/usr/src/kerberosIV).src-lib
release=cvsLibraries
(/usr/src/lib).src-libexec
release=cvsSystem programs normally executed by
other programs
(/usr/src/libexec).src-release
release=cvsFiles required to produce a FreeBSD
release
(/usr/src/release).src-sbin
release=cvsSystem utilities for single-user
mode
(/usr/src/sbin).src-share
release=cvsFiles that can be shared across
multiple systems
(/usr/src/share).src-sys
release=cvsThe kernel
(/usr/src/sys).src-tools
release=cvsVarious tools for the maintenance of
FreeBSD
(/usr/src/tools).src-usrbin
release=cvsUser utilities
(/usr/src/usr.bin).src-usrsbin
release=cvsSystem utilities
(/usr/src/usr.sbin).www
release=cvsThe sources for the World Wide Web
data.cvs-crypto
release=cvsThe export-restricted cryptography code.src-crypto
release=cvsExport-restricted utilities and libraries
from outside the FreeBSD project, used
relatively unmodified
(/usr/src/crypto).src-eBones
release=cvsKerberos and DES
(/usr/src/eBones).src-secure
release=cvsDES
(/usr/src/secure).distrib
release=selfThe CVSup server's own configuration files. Used by
CVSup mirror sites.gnats
release=currentThe GNATS bug-tracking database.mail-archive
release=currentFreeBSD mailing list archive.www
release=currentThe installed World Wide Web data. Used by WWW
mirror sites.Announcements, Questions, and Bug ReportsMost FreeBSD-related discussion of CVSup takes place on the
&a.hackers;. New versions of the software are announced there,
as well as on the &a.announce;.Questions and bug reports should be addressed to the author
of the program at cvsup-bugs@polstra.com.Using make world to rebuild your
systemContributed by &a.nik;.Once you have synchronised your local source tree against a
particular version of FreeBSD (stable,
current and so on) you must then use
the source tree to rebuild the system.Currently, the best source of information on how to do that is a
tutorial available from http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html.A successor to this tutorial will be integrated into the
handbook.
diff --git a/en/handbook/eresources/chapter.sgml b/en/handbook/eresources/chapter.sgml
index c1fcd45ce2..56e4bc2172 100644
--- a/en/handbook/eresources/chapter.sgml
+++ b/en/handbook/eresources/chapter.sgml
@@ -1,1143 +1,1289 @@
Resources on the InternetContributed by &a.jkh;.The rapid pace of FreeBSD progress makes print media impractical
as a means of following the latest developments. Electronic resources
are the best, if not often the only, way stay informed of the latest
advances. Since FreeBSD is a volunteer effort, the user community
itself also generally serves as a “technical support department” of
sorts, with electronic mail and USENET news being the most effective
way of reaching that community.The most important points of contact with the FreeBSD user
community are outlined below. If you are aware of other resources not
mentioned here, please send them to the &a.doc;so that they may also
be included.Mailing listsThough many of the FreeBSD development members read USENET, we
cannot always guarantee that we will get to your questions in a
timely fashion (or at all) if you post them only to one of the
comp.unix.bsd.freebsd.* groups. By addressing your questions to the
appropriate mailing list you will reach both us and a concentrated
FreeBSD audience, invariably assuring a better (or at least faster)
response.The charters for the various lists are given at the bottom of
this document. Please read the charter before
joining or sending mail to any list. Most of our list
subscribers now receive many hundreds of FreeBSD related messages
every day, and by setting down charters and rules for proper use we
are striving to keep the signal-to-noise ratio of the lists high.
To do less would see the mailing lists ultimately fail as an
effective communications medium for the project.Archives are kept for all of the mailing lists and can be
searched using the FreeBSD World Wide Web
server. The keyword searchable archive offers an
excellent way of finding answers to frequently asked questions and
should be consulted before posting a question.List summaryGeneral lists: The following are
general lists which anyone is free (and encouraged) to join:ListPurposefreebsd-advocacyFreeBSD Evangelismfreebsd-announceImportant events and project milestonesfreebsd-bugsBug reportsfreebsd-chatNon-technical items related to the FreeBSD
communityfreebsd-currentDiscussion concerning the use of
FreeBSD-current
-
- freebsd-stable
- Discussion concerning the use of
- FreeBSD-stable
-
-
freebsd-ispIssues for Internet Service Providers using
FreeBSDfreebsd-jobsFreeBSD employment and consulting
opportunitiesfreebsd-newbiesNew FreeBSD users activities and discussionsfreebsd-questions
- User questions
+ User questions and technical support
+
+
+ freebsd-stable
+ Discussion concerning the use of
+ FreeBSD-stable
+
+
Technical lists: The following
lists are for technical discussion. You should read the charter
for each list carefully before joining or sending mail to one as
there are firm guidelines for their use and content.ListPurposefreebsd-afsPorting AFS to FreeBSDfreebsd-alphaPorting FreeBSD to the Alphafreebsd-doc
- The FreeBSD Documentation project
+ Creating FreeBSD related documentsfreebsd-databaseDiscussing database use and development under
FreeBSDfreebsd-emulationEmulation of other systems such as
Linux/DOS/Windowsfreebsd-fsFilesystemsfreebsd-hackersGeneral technical discussionfreebsd-hardwareGeneral discussion of hardware for running
FreeBSDfreebsd-isdnISDN developersfreebsd-javaJava developers and people porting JDKs to
FreeBSDfreebsd-mobileDiscussions about mobile computingfreebsd-mozillaPorting mozilla to FreeBSDfreebsd-netNetworking discussion and TCP/IP/source codefreebsd-platformsConcerning ports to non-Intel architecture
platformsfreebsd-portsDiscussion of the ports collectionfreebsd-scsiThe SCSI subsystemfreebsd-securitySecurity issuesfreebsd-smallUsing FreeBSD in embedded applicationsfreebsd-smpDesign discussions for [A]Symmetric
MultiProcessingfreebsd-sparcPorting FreeBSD to Sparc systemsfreebsd-tokenringSupport Token Ring in FreeBSDLimited lists: The following
lists require approval from core@FreeBSD.ORG to join,
though anyone is free to send messages to them which fall within
the scope of their charters. It is also a good idea establish a
presence in the technical lists before asking to join one of these
limited lists.ListPurposefreebsd-adminAdministrative issuesfreebsd-archArchitecture and design discussionsfreebsd-coreFreeBSD core teamfreebsd-hubsPeople running mirror sites (infrastructural
support)freebsd-installInstallation developmentfreebsd-security-notificationsSecurity notificationsfreebsd-user-groupsUser group coordinationCVS lists: The following lists
are for people interested in seeing the log messages for changes
to various areas of the source tree. They are Read-Only lists and should not have mail
sent to them.ListSource areaArea Description (source for)cvs-all/usr/srcAll changes to the tree (superset)How to subscribeAll mailing lists live on FreeBSD.ORG, so
to post to a given list you simply mail to
listname@FreeBSD.ORG. It will
then be redistributed to mailing list members world-wide.To subscribe to a list, send mail to &a.majordomo; and include
subscribe <listname> [<optional address>]
in the body of your message. For example, to
subscribe yourself to freebsd-announce, you'd do:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce
^DIf you want to subscribe yourself under a
different name, or submit a subscription request for a local
mailing list (this is more efficient if you have several
interested parties at one site, and highly appreciated by us!),
you would do something like:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce local-announce@somesite.com
^DFinally, it is also possible to unsubscribe
yourself from a list, get a list of other list members or see the
list of mailing lists again by sending other types of control
messages to majordomo. For a complete list of available commands,
do this:&prompt.user; mail majordomo@FreeBSD.ORG
help
^DAgain, we would like to request that you keep
discussion in the technical mailing lists on a technical track.
If you are only interested in the “high points” then it is
suggested that you join freebsd-announce, which is intended only
for infrequent traffic.List chartersAllFreeBSD mailing lists have
certain basic rules which must be adhered to by anyone using them.
Failure to comply with these guidelines will result in two (2)
written warnings from the FreeBSD Postmaster postmaster@freebsd.org, after
which, on a third offense, the poster will removed from all
FreeBSD mailing lists and filtered from further posting to them.
We regret that such rules and measures are necessary at all, but
today's Internet is a pretty harsh environment, it would seem, and
many fail to appreciate just how fragile some of its mechanisms
are.Rules of the road:The topic of any posting should adhere to the basic
charter of the list it is posted to, e.g. if the list is
about technical issues then your posting should contain
technical discussion. Ongoing irrelevant chatter or flaming
only detracts from the value of the mailing list for
everyone on it and will not be tolerated. For free-form
discussion on no particular topic, the freebsd-chat freebsd-chat@freebsd.org
mailing list is freely available and should be used
instead.No posting should be made to more than 2 mailing lists,
and only to 2 when a clear and obvious need to post to both
lists exists. For most lists, there is already a great deal
of subscriber overlap and except for the most esoteric mixes
(say "-stable & -scsi"), there really is no reason to
post to more than one list at a time. If a message is sent
to you in such a way that multiple mailing lists appear on
the Cc line then the cc line should also be trimmed before
sending it out again. You are still responsible for your own
cross-postings, no matter who the originator might have
been.Personal attacks and profanity (in the context of an
argument) are not allowed, and that includes users and
developers alike. Gross breaches of netiquette, like
excerpting or reposting private mail when permission to do
so was not and would not be forthcoming, are frowned upon
but not specifically enforced. However, there are also very few cases
where such content would fit within the charter of a list
and it would therefore probably rate a warning (or ban) on
that basis alone.Advertising of non-FreeBSD related products or services
is strictly prohibited and will result in an immediate ban
if it is clear that the offender is advertising by
spam.Individual list charters:FREEBSD-AFSAndrew File SystemThis list is for discussion on porting and using AFS from
CMU/TransarcFREEBSD-ADMINAdministrative issuesThis list is purely for discussion of freebsd.org
related issues and to report problems or abuse of project
resources. It is a closed list, though anyone may report
a problem (with our systems!) to it.FREEBSD-ANNOUNCEImportant events /
milestonesThis is the mailing list for people interested only
in occasional announcements of significant FreeBSD events.
This includes announcements about snapshots and other
releases. It contains announcements of new FreeBSD
capabilities. It may contain calls for volunteers etc.
This is a low volume, strictly moderated mailing
list.FREEBSD-ARCHArchitecture and design
discussionsThis is a moderated list for discussion of FreeBSD
architecture. Messages will mostly be kept technical in
nature, with (rare) exceptions for other messages the
moderator deems need to reach all the subscribers of the
list. Examples of suitable topics;How to re-vamp the build system to have several
customized builds running at the same time.What needs to be fixed with VFS to make Heidemann
layers work.How do we change the device driver interface to be
able to use the ame drivers cleanly on many buses and
architectures?How do I write a network driver?The moderator reserves the right to do minor editing
(spell-checking, grammar correction, trimming) of messages
that are posted to the list. The volume of the list will be
kept low, which may involve having to delay topics until an
active discussion has been resolved.FREEBSD-BUGSBug reportsThis is
the mailing list for reporting bugs in FreeBSD Whenever
possible, bugs should be submitted using the send-pr1
command or the WEB
interface to it.FREEBSD-CHATNon technical items related to the FreeBSD
communityThis list contains the
overflow from the other lists about non-technical, social
information. It includes discussion about whether Jordan
looks like a toon ferret or not, whether or not to type in
capitals, who is drinking too much coffee, where the best
beer is brewed, who is brewing beer in their basement, and
so on. Occasional announcements of important events (such
as upcoming parties, weddings, births, new jobs, etc) can
be made to the technical lists, but the follow ups should
be directed to this -chat list.FREEBSD-COREFreeBSD core teamThis is an internal mailing list for use by the core
members. Messages can be sent to it when a serious
FreeBSD-related matter requires arbitration or high-level
scrutiny.FREEBSD-CURRENTDiscussions about the use of
FreeBSD-currentThis is the
mailing list for users of freebsd-current. It includes
warnings about new features coming out in -current that
will affect the users, and instructions on steps that must
be taken to remain -current. Anyone running “current” must
subscribe to this list. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-CURRENT-DIGESTDiscussions about the use of
FreeBSD-currentThis is the
digest version of the freebsd-current mailing list. The
digest consists of all messages sent to freebsd-current
bundled together and mailed out as a single message. The
average digest size is about 40kB. This list is Read-Only and should not be posted
to.
- FREEBSD-STABLE
-
-
- Discussions about the use of
- FreeBSD-stable
-
- This is the
- mailing list for users of freebsd-stable. It includes
- warnings about new features coming out in -stable that
- will affect the users, and instructions on steps that must
- be taken to remain -stable. Anyone running “stable”
- should subscribe to this list. This is a technical mailing
- list for which strictly technical content is
- expected.
-
-
-
FREEBSD-DOCDocumentation project
- This mailing list is for the discussion of documentation
- related issues and projects. The members of this mailing list
- are collectively referred to as “The FreeBSD
- Documentation Project”. It is an open list; feel free to
- join and contribute.
+ This mailing list is for the discussion of issues and
+ projects related to the creation of documenation for
+ FreeBSD. The members of this mailing list are collectively
+ referred to as “The FreeBSD Documentation
+ Project”. It is an open list; feel free to join and
+ contribute!FREEBSD-FSFilesystemsDiscussions concerning FreeBSD filesystems. This is a
technical mailing list for which strictly technical
content is expected.FREEBSD-ISDNISDN CommunicationsThis is the mailing list for people discussing the
development of ISDN support for FreeBSD.FREEBSD-JAVAJava Development
This is the mailing list for people discussing the
development of significant Java applications for FreeBSD
and the porting and maintenance of JDKs.FREEBSD-HACKERSTechnical discussionsThis is a forum for technical discussions related to
FreeBSD. This is the primary technical mailing list. It
is for individuals actively working on FreeBSD, to bring
up problems or discuss alternative solutions. Individuals
interested in following the technical discussion are also
welcome. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-HACKERS-DIGESTTechnical discussionsThis is the digest version of the freebsd-hackers
mailing list. The digest consists of all messages sent to
freebsd-hackers bundled together and mailed out as a
single message. The average digest size is about 40kB.
This list is Read-Only and
should not be posted to.FREEBSD-HARDWAREGeneral discussion of FreeBSD
hardwareGeneral discussion
about the types of hardware that FreeBSD runs on, various
problems and suggestions concerning what to buy or
avoid.FREEBSD-INSTALLInstallation discussionThis mailing list is for discussing FreeBSD
installation development for the future releases and is
closed.FREEBSD-ISPIssues for Internet Service
ProvidersThis mailing list is
for discussing topics relevant to Internet Service
Providers (ISPs) using FreeBSD. This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-NEWBIESNewbies activities
discussionWe cover any of the activities of newbies that are not
already dealt with elsewhere, including: independent learning
and problem solving techniques, finding and using resources
and asking for help elsewhere, how to use mailing lists and
which lists to use, general chat, making mistakes, boasting,
sharing ideas, stories, moral (but not technical) support, and
taking an active part in the FreeBSD community. We take our
problems and support questions to freebsd-questions, and use
freebsd-newbies to meet others who are doing the same things
that we do as newbies.FREEBSD-PLATFORMSPorting to Non-Intel
platformsCross-platform freebsd
issues, general discussion and proposals for non-Intel
FreeBSD ports. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-PORTSDiscussion of
“ports”Discussions concerning FreeBSD's “ports collection”
(/usr/ports), proposed ports, modifications to ports
collection infrastructure and general coordination
efforts. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-QUESTIONSUser questionsThis
is the mailing list for questions about FreeBSD. You
should not send “how to” questions to the technical lists
unless you consider the question to be pretty
technical.FREEBSD-QUESTIONS-DIGESTUser questionsThis
is the digest version of the freebsd-questions mailing
list. The digest consists of all messages sent to
freebsd-questions bundled together and mailed out as a
single message. The average digest size is about
40kB.FREEBSD-SCSISCSI subsystemThis
is the mailing list for people working on the scsi
subsystem for FreeBSD. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-SECURITYSecurity issuesFreeBSD computer security issues (DES, Kerberos, known
security holes and fixes, etc). This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-SECURITY-NOTIFICATIONSSecurity Notifications Notifications of FreeBSD security problems and fixes.
This is not a discussion list. The discussion list is
FreeBSD-security.FREEBSD-SMALLThis list discusses topics related to unsually small and
embedded FreeBSD installations. This is a technical mailing
list for which strictly technical content is expected.
- FREEBSD-USER-GROUPS
+ FREEBSD-STABLE
+
+
+ Discussions about the use of
+ FreeBSD-stable
+
+ This is the
+ mailing list for users of freebsd-stable. It includes
+ warnings about new features coming out in -stable that
+ will affect the users, and instructions on steps that must
+ be taken to remain -stable. Anyone running “stable”
+ should subscribe to this list. This is a technical mailing
+ list for which strictly technical content is
+ expected.
+
+
+
+ FREEBSD-USER-GROUPSUser Group Coordination
ListThis is the mailing list for the coordinators from
each of the local area Users Groups to discuss matters
with each other and a designated individual from the Core
Team. This mail list should be limited to meeting
synopsis and coordination of projects that span User
Groups. It is a closed list.Usenet newsgroupsIn addition to two FreeBSD specific newsgroups, there are many
others in which FreeBSD is discussed or are otherwise relevant to
FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.oz.au.BSD specific newsgroupscomp.unix.bsd.freebsd.announcecomp.unix.bsd.freebsd.miscOther Unix newsgroups of interestcomp.unixcomp.unix.questionscomp.unix.admincomp.unix.programmercomp.unix.shellcomp.unix.user-friendlycomp.security.unixcomp.sources.unixcomp.unix.advocacycomp.unix.misccomp.bugs.4bsdcomp.bugs.4bsd.ucb-fixescomp.unix.bsdX Window Systemcomp.windows.x.i386unixcomp.windows.xcomp.windows.x.appscomp.windows.x.announcecomp.windows.x.intrinsicscomp.windows.x.motifcomp.windows.x.pexcomp.emulators.ms-windows.wineWorld Wide Web servershttp://www.FreeBSD.ORG/ — Central Server.http://www.au.freebsd.org/FreeBSD/ — Australia.
+ URL="http://www.au.freebsd.org/FreeBSD/">http://www.au.freebsd.org/FreeBSD/ — Australia/1.
+
+
+
+ http://www2.au.freebsd.org/FreeBSD/ — Australia/2.
+
+
+
+ http://www3.au.freebsd.org/FreeBSD/ — Australia/3.
+
+
+
+ http://www.br.freebsd.org/www.freebsd.org/ — Brazil/1.
+
+
+
+ http://www.br2.freebsd.org/www.freebsd.org/ — Brazil/2.
+
+
+
+ http://www3.br.freebsd.org/ — Brazil/3.http://www.br.freebsd.org/ — Brazil.
+ URL="http://www.bg.freebsd.org/">http://www.bg.freebsd.org/ — Bulgaria.
http://www.ca.freebsd.org/ — Canada.
+ URL="http://www.ca.freebsd.org/">http://www.ca.freebsd.org/ — Canada/1.
http://sunsite.mff.cuni.cz/www.freebsd.org/ — Czech Republic.
+ URL="http://freebsd.kawartha.com/">http://freebsd.kawartha.com/ — Canada/2.
http://sunsite.auc.dk/www.freebsd.org/ — Denmark.
+ URL="http://www.dk.freebsd.org/">http://www.dk.freebsd.org/ — Denmark.
http://www.ee.freebsd.org/ — Estonia.http://www.fi.freebsd.org/ — Finland.
+
+
+ http://www.fr.freebsd.org/ — France.
+
+
+
+ http://www.de.freebsd.org/ — Germany/1.
+
+
+
+ http://www1.de.freebsd.org/ — Germany/2.
+
+
+
+ http://www.de.freebsd.org/ — Germany/3.
+
+
+
+ http://www.hu.freebsd.org/ — Hungary.
+ http://www.de.freebsd.org/ — Germany.
+ URL="http://www.is.freebsd.org/">http://www.is.freebsd.org/ — Iceland.
http://www.ie.freebsd.org/ — Ireland.http://www.jp.freebsd.org/ — Japan.
+ URL="http://www.jp.freebsd.org/www.freebsd.org/">http://www.jp.freebsd.org/www.freebsd.org/ — Japan.
http://www.kr.freebsd.org/ — Korea.
+
+ http://www.lv.freebsd.org/ — Latvia.
+
+
+
+ http://rama.asiapac.net/freebsd/ — Malaysia.
+
+
http://www.nl.freebsd.org/ — Netherlands.http://www.pt.freebsd.org/ — Portugal.
+ URL="http://www.no.freebsd.org/">http://www.no.freebsd.org/ — Norway.
+
+
+
+ http://www.pt.freebsd.org/ — Portugal/1.
+
+
+
+ http://www2.pt.freebsd.org/ — Portugal/2.
+
+
+
+ http://www3.pt.freebsd.org/ — Portugal/3.
+
+
+
+ http://www.ro.freebsd.org/ — Romania.
+
+
+
+ http://www.ru.freebsd.org/ — Russia/1.
+
+
+
+ http://www2.ru.freebsd.org/ — Russia/2.
+
+
+
+ http://www3.ru.freebsd.org/ — Russia/3.
+
+
+
+ http://www.sk.freebsd.org/ — Slovak Republic.
+
+
+
+ http://www.si.freebsd.org/ — Slovenia.
+
+
+
+ http://www.es.freebsd.org/ — Spain.
+
+
+
+ http://www.za.freebsd.org/ — South Africa/1.
+
+
+
+ http://www2.za.freebsd.org/ — South Africa/2.http://www.se.freebsd.org/www.freebsd.org/ — Sweden.http://www.tw.freebsd.org/freebsd.html — Taiwan.
+ URL="http://www.tr.freebsd.org/">http://www.tr.freebsd.org/ — Turkey.
+
+
+
+ http://www.ua.freebsd.org/ — Ukraine/1.
+
+
+
+ http://www2.ua.freebsd.org/ — Ukraine/2.
+
+
+
+ http://www.uk.freebsd.org/ — United Kingdom.
+
+
+
+ http://freebsd.advansys.net/ — USA/Indiana.http://www2.ua.freebsd.org/ — Ukraine.
+ URL="http://www6.freebsd.org/">http://www6.freebsd.org/ — USA/Oregon.
+
+ http://www2.freebsd.org/ — USA/Texas.
+
diff --git a/en/handbook/handbook.sgml b/en/handbook/handbook.sgml
index a4c9c067df..fb72c6e754 100644
--- a/en/handbook/handbook.sgml
+++ b/en/handbook/handbook.sgml
@@ -1,111 +1,112 @@
%chapters;
%authors;
%mailing-lists;
]>
FreeBSD HandbookThe FreeBSD Documentation ProjectJuly 19981995199619971998The FreeBSD Documentation Project, FreeBSD Inc.Welcome to FreeBSD! This handbook covers the installation and day
to day use of FreeBSD Release &rel.current;. This
manual is a work in progress and is the work of
many individuals. Many sections do not yet exist and some of those
that do exist need to be updated. If you are interested in helping
- with this project, send email to the &a.doc; The latest version of
+ with this project, send email to the &a.doc;. The latest version of
this document is always available from the FreeBSD World Wide Web server.
It may also be downloaded in plain
text, postscript or HTML with HTTP or gzip'd from the FreeBSD FTP server or one of the numerous FreeBSD FTP server or one of the numerous mirror sites. You may also want to
Search the Handbook.Getting Started
&chap.introduction;
&chap.install;
&chap.basics;
&chap.ports
System Administration
&chap.kernelconfig;
&chap.security;
&chap.printing;
&chap.disks;
&chap.backups;
&chap.quotas;
&chap.x11;
&chap.hw;
&chap.l10n;
Network Communications
&chap.serialcomms;
&chap.ppp-and-slip;
&chap.advanced-networking;
&chap.mail;
Advanced topics
&chap.cutting-edge;
&chap.contrib;
&chap.policies;
&chap.kernelopts;
&chap.kerneldebug;
&chap.linuxemu;
&chap.internals;
Appendices
&chap.mirrors;
&chap.bibliography;
&chap.eresources;
&chap.staff;
&chap.pgpkeys;
diff --git a/en/handbook/introduction/chapter.sgml b/en/handbook/introduction/chapter.sgml
index 163e13428a..77510aa99d 100644
--- a/en/handbook/introduction/chapter.sgml
+++ b/en/handbook/introduction/chapter.sgml
@@ -1,622 +1,626 @@
IntroductionFreeBSD is a 4.4BSD-Lite based operating system for Intel
architecture (x86) based PCs. For an overview of FreeBSD, see
FreeBSD in a nutshell. For a
history of the project, read a brief
history of FreeBSD. To see a description of the latest release,
read about the current
release. If you're interested in contributing something to the
FreeBSD project (code, equipment, sacks of unmarked bills), please see
about contributing to FreeBSD.FreeBSD in a NutshellFreeBSD is a state of the art operating system for personal
computers based on the Intel CPU architecture, which includes the
386, 486 and Pentium processors (both SX and DX versions). Intel
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
provides you with many advanced features previously available only
on much more expensive computers. These features include:Preemptive multitasking with
dynamic priority adjustment to ensure smooth and fair sharing
of the computer between applications and users.Multiuser access means that
many people can use a FreeBSD system simultaneously for a
variety of things. System peripherals such as printers and
tape drives are also properly SHARED BETWEEN ALL users on the
system.Complete TCP/IP networking
including SLIP, PPP, NFS and NIS support. This means that
your FreeBSD machine can inter-operate easily with other
systems as well act as an enterprise server, providing vital
functions such as NFS (remote file access) and e-mail services
or putting your organization on the Internet with WWW, ftp,
routing and firewall (security) services.Memory protection ensures
that applications (or users) cannot interfere with each other.
One application crashing will not affect others in any
way.FreeBSD is a 32-bit
operating system and was designed as such from the ground
up.The industry standard X Window
System (X11R6) provides a graphical user
interface (GUI) for the cost of a common VGA card and monitor
and comes with full sources.Binary compatibility with
many programs built for SCO, BSDI, NetBSD, Linux and
386BSD.Hundreds of ready-to-run
applications are available from the FreeBSD ports and packages collection. Why search the net
when you can find it all right here?Thousands of additional and easy-to-port applications available on
the Internet. FreeBSD is source code compatible with most
popular commercial Unix systems and thus most applications
require few, if any, changes to compile.Demand paged virtual memory
and “merged VM/buffer cache” design efficiently satisfies
applications with large appetites for memory while still
maintaining interactive response to other users.Shared libraries (the Unix
equivalent of MS-Windows DLLs) provide for efficient use of
disk space and memory.A full complement of C,
C++ and Fortran development tools. Many
additional languages for advanced research and development are
also available in the ports and packages collection.Source code for the entire
system means you have the greatest degree of control over your
environment. Why be locked into a proprietary solution and at
the mercy of your vendor when you can have a truly Open
System?Extensive on-line
documentation.And many more!FreeBSD is based on the 4.4BSD-Lite release from Computer
Systems Research Group (CSRG) at the University of California at
Berkeley, and carries on the distinguished tradition of BSD systems
development. In addition to the fine work provided by CSRG, the
FreeBSD Project has put in many thousands of hours in fine tuning
the system for maximum performance and reliability in real-life load
situations. As many of the commercial giants struggle to field PC
operating systems with such features, performance and reliability,
FreeBSD can offer them now!The applications to which FreeBSD can be put are truly limited
only by your own imagination. From software development to factory
automation, inventory control to azimuth correction of remote
satellite antennae; if it can be done with a commercial UNIX product
then it is more than likely that you can do it with FreeBSD, too!
FreeBSD also benefits significantly from the literally thousands of
high quality applications developed by research centers and
universities around the world, often available at little to no cost.
Commercial applications are also available and appearing in greater
numbers every day.Because the source code for FreeBSD itself is generally
available, the system can also be customized to an almost unheard of
degree for special applications or projects, and in ways not
generally possible with operating systems from most major commercial
vendors. Here is just a sampling of some of the applications in
which people are currently using FreeBSD:Internet Services: The
robust TCP/IP networking built into FreeBSD makes it an ideal
platform for a variety of Internet services such as:FTP serversWorld Wide Web serversGopher serversElectronic Mail serversUSENET NewsBulletin Board SystemsAnd more...You can easily start out small with an
inexpensive 386 class PC and upgrade as your enterprise
grows.Education: Are you a student
of computer science or a related engineering field? There is
no better way of learning about operating systems, computer
architecture and networking than the hands on, under the hood
experience that FreeBSD can provide. A number of freely
available CAD, mathematical and graphic design packages also
make it highly useful to those whose primary interest in a
computer is to get other work
done!Research: With source code
for the entire system available, FreeBSD is an excellent
platform for research in operating systems as well as other
branches of computer science. FreeBSD's freely available
nature also makes it possible for remote groups to collaborate
on ideas or shared development without having to worry about
special licensing agreements or limitations on what may be
discussed in open forums.Networking: Need a new
router? A name server (DNS)? A firewall to keep people out
of your internal network? FreeBSD can easily turn that unused
386 or 486 PC sitting in the corner into an advanced router
with sophisticated packet filtering capabilities.X Window workstation:
FreeBSD is a fine choice for an inexpensive X terminal
solution, either using the freely available XFree86 server or
one of the excellent commercial servers provided by X Inside.
Unlike an X terminal, FreeBSD allows many applications to be
run locally, if desired, thus relieving the burden on a
central server. FreeBSD can even boot “diskless”, making
individual workstations even cheaper and easier to
administer.Software Development: The
basic FreeBSD system comes with a full complement of
development tools including the renowned GNU C/C++ compiler
and debugger.FreeBSD is available in both source and binary form on CDROM and
via anonymous ftp. See Obtaining
FreeBSD for more details.A Brief History of FreeBSDContributed by &a.jkh;.The FreeBSD project had its genesis in the early part of 1993,
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
myself.Our original goal was to produce an intermediate snapshot of
386BSD in order to fix a number of problems with it that the
patchkit mechanism just was not capable of solving. Some of you may
remember the early working title for the project being “386BSD 0.5”
or “386BSD Interim” in reference to that fact.386BSD was Bill Jolitz's operating system, which had been up to
that point suffering rather severely from almost a year's worth of
neglect. As the patchkit swelled ever more uncomfortably with each
passing day, we were in unanimous agreement that something had to be
done and decided to try and assist Bill by providing this interim
“cleanup” snapshot. Those plans came to a rude halt when Bill
Jolitz suddenly decided to withdraw his sanction from the project
and without any clear indication of what would be done
instead.It did not take us long to decide that the goal remained
worthwhile, even without Bill's support, and so we adopted the name
“FreeBSD”, coined by David Greenman. Our initial objectives were
set after consulting with the system's current users and, once it
became clear that the project was on the road to perhaps even
becoming a reality, I contacted Walnut Creek CDROM with an eye
towards improving FreeBSD's distribution channels for those many
unfortunates without easy access to the Internet. Walnut Creek
CDROM not only supported the idea of distributing FreeBSD on CD but
went so far as to provide the project with a machine to work on and
a fast Internet connection. Without Walnut Creek CDROM's almost
unprecedented degree of faith in what was, at the time, a completely
unknown project, it is quite unlikely that FreeBSD would have gotten
as far, as fast, as it has today.The first CDROM (and general net-wide) distribution was FreeBSD
1.0, released in December of 1993. This was based on the
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
also provided by 386BSD and the Free Software Foundation. It was a
fairly reasonable success for a first offering, and we followed it
with the highly successful FreeBSD 1.1 release in May of
1994.Around this time, some rather unexpected storm clouds formed on
the horizon as Novell and U.C. Berkeley settled their long-running
lawsuit over the legal status of the Berkeley Net/2 tape. A
condition of that settlement was U.C. Berkeley's concession that
large parts of Net/2 were “encumbered” code and the property of
Novell, who had in turn acquired it from AT&T some time
previously. What Berkeley got in return was Novell's “blessing”
that the 4.4BSD-Lite release, when it was finally released, would be
declared unencumbered and all existing Net/2 users would be strongly
encouraged to switch. This included FreeBSD, and the project was
given until the end of July 1994 to stop shipping its own Net/2
based product. Under the terms of that agreement, the project was
allowed one last release before the deadline, that release being
FreeBSD 1.1.5.1.FreeBSD then set about the arduous task of literally
re-inventing itself from a completely new and rather incomplete set
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
Berkeley's CSRG had removed large chunks of code required for
actually constructing a bootable running system (due to various
legal requirements) and the fact that the Intel port of 4.4 was
highly incomplete. It took the project until December of 1994 to
make this transition, and in January of 1995 it released FreeBSD 2.0
to the net and on CDROM. Despite being still more than a little
rough around the edges, the release was a significant success and
was followed by the more robust and easier to install FreeBSD 2.0.5
release in June of 1995.We released FreeBSD 2.1.5 in August of 1996, and it appeared to
be popular enough among the ISP and commercial communities that
another release along the 2.1-stable branch was merited. This was
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
mainstream development on 2.1-stable. Now in maintenance mode, only
security enhancements and other critical bug fixes will be done on
this branch (RELENG_2_1_0).FreeBSD 2.2 was branched from the development mainline
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
first full release (2.2.1) was released in April, 1997. Further
releases along the 2.2 branch were done in the Summer and Fall of
'97, the latest being 2.2.7 which appeared in late July of '98.
- The first official 3.0 release will appear in October, 1998 and the
- last release on the 2.2 branch, 2.2.8, will appear in November.
-
- Long term development projects for everything from SMP to DEC
- ALPHA support will continue to take place in the 3.0-current branch
- and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).
-
+ The first official 3.0 release appeared in October, 1998 and the
+ last release on the 2.2 branch, 2.2.8, appeared in November,
+ 1998.
+
+ The tree branched again on Jan 20, 1999. This led to
+ 4.0-current and a 3.x-stable branch, from which 3.1 will be
+ released on February 15th, 1999.
+
+ Long term development projects will continue to take place in
+ the 4.0-current branch and SNAPshot releases of 4.0 on CDROM (and,
+ of course, on the net).FreeBSD Project GoalsContributed by &a.jkh;.The goals of the FreeBSD Project are to provide software that
may be used for any purpose and without strings attached. Many of
us have a significant investment in the code (and project) and would
certainly not mind a little financial compensation now and then, but
we're definitely not prepared to insist on it. We believe that our
first and foremost “mission” is to provide code to any and all
comers, and for whatever purpose, so that the code gets the widest
possible use and provides the widest possible benefit. This is, I
believe, one of the most fundamental goals of Free Software and one
that we enthusiastically support.That code in our source tree which falls under the GNU Public
License (GPL) or GNU Library Public License (GLPL) comes with
slightly more strings attached, though at least on the side of
enforced access rather than the usual opposite. Due to the
additional complexities that can evolve in the commercial use of GPL
software, we do, however, endeavor to replace such software with
submissions under the more relaxed BSD copyright whenever possible.The FreeBSD Development ModelContributed by &a.asami;.The development of FreeBSD is a very open and flexible process,
FreeBSD being literally built from the contributions of hundreds of
people around the world, as can be seen from our list of contributors. We are constantly
on the lookout for new developers and ideas, and those interested in
becoming more closely involved with the project need simply contact
us at the &a.hackers;. Those who prefer to work more independently
are also accommodated, and they are free to use our FTP facilities
at ftp.freebsd.org to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.Useful things to know about the FreeBSD project and its
development process, whether working independently or in close
cooperation:The CVS
repositoryThe central source tree for FreeBSD is maintained by
CVS (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary CVS repository resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the -current and -stable trees which are checked
out of it, can be easily replicated to your own machine as
well. Please refer to the
Synchronizing your source
tree section for more information on doing this.The committers
listThe committers
are the people who have write access to
the CVS tree, and are thus authorized to make modifications
to the FreeBSD source (the term “committer” comes from the
cvs1commit command, which is used to
bring new changes into the CVS repository). The best way of
making submissions for review by the committers list is to
use the send-pr1 command, though if something appears to be jammed in the system then you may also reach them by sending mail to committers@freebsd.org.The FreeBSD core
teamThe FreeBSD core
team would be equivalent to the board of directors if
the FreeBSD Project were a company. The primary task of the
core team is to make sure the project, as a whole, is in
good shape and is heading in the right directions. Inviting
dedicated and responsible developers to join our group of
committers is one of the functions of the core team, as is
the recruitment of new core team members as others move on.
Most current members of the core team started as committers
who's addiction to the project got the better of
them.Some core team members also have specific areas of responsibility,
meaning that they are committed to ensuring that some large
portion of the system works as advertised.Most members of the core team are volunteers when it
comes to FreeBSD development and do not benefit from the
project financially, so “commitment” should also not be
misconstrued as meaning “guaranteed support.” The
“board of directors” analogy above is not
actually very accurate, and it may be more suitable to say
that these are the people who gave up their lives in favor
of FreeBSD against their better judgement! ;)Outside
contributorsLast, but definitely not least, the largest group of
developers are the users themselves who provide feedback and
bug-fixes to us on an almost constant basis. The primary
way of keeping in touch with FreeBSD's more non-centralized
development is to subscribe to the &a.hackers; (see mailing list
info) where such things are discussed.The list of
those who have contributed something which made its way into
our source tree is a long and growing one, so why not join
it by contributing something back to FreeBSD today?
:-)Providing code is not the only way of contributing to
the project; for a more complete list of things that need
doing, please refer to the how to
contribute section in this handbook.In summary, our development model is organized as a loose set of
concentric circles. The centralized model is designed for the
convenience of the users of FreeBSD, who are
thereby provided with an easy way of tracking one central code base,
not to keep potential contributors out! Our desire is to present a
stable operating system with a large set of coherent application programs that the users can easily install
and use, and this model works very well in accomplishing
that.All we ask of those who would join us as FreeBSD developers is
some of the same dedication its current people have to its continued
success!About the Current ReleaseFreeBSD is a freely available, full source 4.4BSD-Lite based
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
compatible) based PC's. It is based primarily on software from U.C.
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
386BSD, and the Free Software Foundation.Since our release of FreeBSD 2.0 in January of 95, the
performance, feature set, and stability of FreeBSD has improved
dramatically. The largest change is a revamped virtual memory
system with a merged VM/file buffer cache that not only increases
performance, but reduces FreeBSD's memory footprint, making a 5MB
configuration a more acceptable minimum. Other enhancements include
full NIS client and server support, transaction TCP support,
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
bug fixes.We have also taken the comments and suggestions of many of our
users to heart and have attempted to provide what we hope is a more
sane and easily understood installation process. Your feedback on
this (constantly evolving) process is especially welcome!In addition to the base distributions, FreeBSD offers a new
ported software collection with hundreds of commonly sought-after
programs. At the end of August 1998 there were more than 1700 ports!
The list of ports ranges from http (WWW) servers, to games,
languages, editors and almost everything in between. The entire
ports collection requires approximately 26MB of storage, all ports
being expressed as “deltas” to their original sources. This
makes it much easier for us to update ports, and greatly reduces
the disk space demands made by the older 1.0 ports collection. To
compile a port, you simply change to the directory of the program
you wish to install, type make all followed by make install
after successful compilation and let the system do the rest. The
full original distribution for each port you build is retrieved
dynamically off the CDROM or a local ftp site, so you need only
enough disk space to build the ports you want. (Almost) every port
is also provided as a pre-compiled “package” which can be installed
with a simple command (pkg_add) by those who do not wish to compile
their own ports from source.A number of additional documents which you may find very helpful
in the process of installing and using FreeBSD may now also be found
in the /usr/share/doc directory on any machine
running FreeBSD 2.1 or later. You may view the locally installed
manuals with any HTML capable browser using the following
URLs:The FreeBSD handbookfile:/usr/share/doc/handbook/handbook.htmlThe FreeBSD FAQfile:/usr/share/doc/FAQ/FAQ.htmlYou can also visit the master (and most frequently updated)
copies at http://www.freebsd.org.The core of FreeBSD does not contain DES code which would
inhibit its being exported outside the United States. There is an
add-on package to the core distribution, for use only in the United
States, that contains the programs that normally use DES. The
auxiliary packages provided separately can be used by anyone. A
freely (from outside the U.S.) exportable European distribution of
DES for our non-U.S. users also exists and is described in the
FreeBSD FAQ.If password security for FreeBSD is all you need, and you have
no requirement for copying encrypted passwords from different hosts
(Suns, DEC machines, etc) into FreeBSD password entries, then
FreeBSD's MD5 based security may be all you require! We feel that
our default security model is more than a match for DES, and without
any messy export issues to deal with. If you are outside (or even
inside) the U.S., give it a try!
diff --git a/en/handbook/kernelconfig/chapter.sgml b/en/handbook/kernelconfig/chapter.sgml
index f40cd2f2d3..35d0fd1e36 100644
--- a/en/handbook/kernelconfig/chapter.sgml
+++ b/en/handbook/kernelconfig/chapter.sgml
@@ -1,1709 +1,1711 @@
Configuring the FreeBSD KernelContributed by &a.jehamby;.6 October
1995.This large section of the handbook discusses the basics of
building your own custom kernel for FreeBSD. This section is
appropriate for both novice system administrators and those with
advanced Unix experience.Why Build a Custom Kernel?Building a custom kernel is one of the most important rites of
passage every Unix system administrator must endure. This process,
while time-consuming, will provide many benefits to your FreeBSD
system. Unlike the GENERIC kernel, which must support every
possible SCSI and network card, along with tons of other rarely used
hardware support, a custom kernel only contains support for
your PC's hardware. This has a number of
benefits:It will take less time to boot because it does not have to
spend time probing for hardware which you do not have.A custom kernel often uses less memory, which is important
because the kernel is the one process which must always be
present in memory, and so all of that unused code ties up
pages of RAM that your programs would otherwise be able to
use. Therefore, on a system with limited RAM, building a
custom kernel is of critical importance.Finally, there are several kernel options which you can
tune to fit your needs, and device driver support for things
like sound cards which you can include in your kernel but are
not present in the GENERIC kernel.Building and Installing a Custom KernelFirst, let us take a quick tour of the kernel build directory.
All directories mentioned will be relative to the main
/usr/src/sys directory, which is also
accessible through /sys. There are a number of
subdirectories here representing different parts of the kernel, but
the most important, for our purposes, are
i386/conf, where you will edit your custom
kernel configuration, and compile,
which is the staging area where your kernel will be built. Notice
the logical organization of the directory tree, with each supported
device, filesystem, and option in its own subdirectory. Also,
anything inside the i386 directory deals with
PC hardware only, while everything outside the
i386 directory is common to all platforms which
FreeBSD could potentially be ported to.If there is not a
/usr/src/sys directory on your system, then
- the kernel source has not been been installed. Follow the
- instructions for installing packages to add this package to your
- system.
+ the kernel source has not been been installed. The easiest way
+ to do this is by running /stand/sysinstall as
+ root, choosing Configure,
+ then Distributions, then src,
+ then sys.
Next, move to the i386/conf directory and
copy the GENERIC configuration file to the name
you want to give your kernel. For example:&prompt.root; cd /usr/src/sys/i386/conf
&prompt.root; cp GENERIC MYKERNELTraditionally, this name is in all capital
letters and, if you are maintaining multiple FreeBSD machines with
different hardware, it is a good idea to name it after your
machine's hostname. We will call it MYKERNEL
for the purpose of this example.You must execute these and all of the following commands
under the root account or you will get permission denied
errors.Now, edit MYKERNEL with your favorite text
editor. If you are just starting out, the only editor available
will probably be vi, which is too
complex to explain here, but is covered well in many books in the
bibliography. Feel free to change
the comment lines at the top to reflect your configuration or the
changes you have made to differentiate it from
GENERIC.If you have build a kernel under SunOS or some other BSD
operating system, much of this file will be very familiar to you. If
you are coming from some other operating system such as DOS, on the
other hand, the GENERIC configuration file
might seem overwhelming to you, so follow the descriptions in the
Configuration File section slowly and carefully.If you are trying to upgrade your kernel from an older version
of FreeBSD, you will probably have to get a new version of
config8 from the same place you got the new
kernel sources. It is located in
/usr/src/usr.sbin, so you will need to
download those sources as well. Re-build and install it before
running the next commands.When you are finished, type the following to compile and install
your kernel:&prompt.root; /usr/sbin/config MYKERNEL
&prompt.root; cd ../../compile/MYKERNEL
&prompt.root; make depend
&prompt.root; make
&prompt.root; make installThe new kernel will be copied to the root
directory as /kernel and the old kernel will be
moved to /kernel.old. Now, shutdown the system
and reboot to use your kernel. In case something goes wrong, there
are some troubleshooting instructions at the end of this document.
Be sure to read the section which explains how to recover in case
your new kernel does not boot.If you have added any new devices (such as sound cards) you
may have to add some device nodes to your
/dev directory before you can use
them.The Configuration FileThe general format of a configuration file is quite simple. Each
line contains a keyword and one or more arguments. For simplicity,
most lines only contain one argument. Anything following a
# is considered a comment and ignored.
The following sections describe each keyword, generally in the order
they are listed in GENERIC, although some
related keywords have been grouped together in a single section
(such as Networking) even though they are actually scattered
throughout the GENERIC file.
An exhaustive list of options and
more detailed explanations of the device lines is present in the
LINT configuration file, located in the same
directory as GENERIC. If you are in doubt as to
the purpose or necessity of a line, check first in
LINT.The kernel is currently being moved to a better organization of
the option handling. Traditionally, each option in the config file
was simply converted into a switch for the
CFLAGS line of the kernel Makefile. Naturally,
this caused a creeping optionism, with nobody really knowing which
option has been referenced in what files.In the new scheme, every #ifdef
that is intended to be dependent upon an option gets this option out
of an opt_foo.h
declaration file created in the compile directory by config. The list of valid options for
config lives in two files: options
that do not depend on the architecture are listed in
/sys/conf/options, architecture-dependent ones
in
/sys/arch/conf/options.arch, with arch being for example i386.Mandatory KeywordsThese keywords are required in every kernel you build.machine "i386"The first keyword is machine, which, since FreeBSD only
runs on Intel 386 and compatible chips, is i386.Any keyword which contains numbers used as text
must be enclosed in quotation marks, otherwise
config gets confused and thinks you
mean the actual number 386.cpu "cpu_type"The next keyword is cpu,
which includes support for each CPU supported by FreeBSD.
The possible values of cpu_type
include:I386_CPUI486_CPUI586_CPUI686_CPUMultiple instances of the cpu line may be present with
different values of cpu_type
as are present in the GENERIC kernel.
For a custom kernel, it is best to specify only the cpu
you have. If, for example, you have an Intel Pentium, use
I586_CPU for cpu_type.ident machine_nameNext, we have ident,
which is the identification of the kernel. You should
change this from GENERIC to whatever
you named your kernel, in this example,
MYKERNEL. The value you put in
ident will print when you
boot up the kernel, so it is useful to give a kernel a
different name if you want to keep it separate from your
usual kernel (if you want to build an experimental kernel,
for example). Note that, as with machine and
cpu, enclose your kernel's name in quotation
marks if it contains any numbers.Since this name is passed to the C compiler as a
switch, do not use names like
DEBUG, or something that could be
confused with another machine or CPU name, like vax.maxusers numberThis file sets the size of a number of important
system tables. This number is supposed to be roughly
equal to the number of simultaneous users you expect to
have on your machine. However, under normal
circumstances, you will want to set
maxusers to at least 4,
especially if you are using the X Window System or
compiling software. The reason is that the most important
table set by maxusers is the
maximum number of processes, which is set to 20 + 16 *
maxusers, so if you set
maxusers to 1, then you
can only have 36 simultaneous processes, including the 18
or so that the system starts up at boot time, and the 15
or so you will probably create when you start the X Window
System. Even a simple task like reading a man page will start up nine
processes to filter, decompress, and view it. Setting
maxusers to 4 will allow you
to have up to 84 simultaneous processes, which should be
enough for anyone. If, however, you see the dreaded
proc table full error when trying to start another
program, or are running a server with a large number of
simultaneous users (like Walnut Creek CDROM's FTP site),
you can always increase this number and rebuild.maxuser does
not limit the number of users which
can log into your machine. It simply sets various table
sizes to reasonable values considering the maximum
number of users you will likely have on your system and
how many processes each of them will be running. One
keyword which does limit the number
of simultaneous remote logins is
pseudo-device pty
16.config kernel_name root on
root_deviceThis line specifies the location and name of the
kernel. Traditionally the kernel is called
vmunix but in FreeBSD, it is aptly
named kernel. You should always use
kernel for
kernel_name because changing it will
render numerous system utilities inoperative. The second
part of the line specifies the disk and partition where
the root filesystem and kernel can be found. Typically
this will be wd0 for systems
with non-SCSI drives, or sd0
for systems with SCSI drives.General OptionsThese lines provide kernel support for various filesystems and
other options.options MATH_EMULATEThis line allows the kernel to simulate a math
co-processor if your computer does not have one (386 or
486SX). If you have a Pentium, a 486DX, or a 386 or 486SX
with a separate 387 or 487 chip, you can comment this line
out.The normal math co-processor emulation routines that
come with FreeBSD are not very
accurate. If you do not have a math co-processor, and
you need the best accuracy, I recommend that you change
this option to GPL_MATH_EMULATE to use
the superior GNU math support, which is not included by
default for licensing reasons.options "COMPAT_43"Compatibility with 4.3BSD. Leave this in; some
programs will act strangely if you comment this
out.options BOUNCE_BUFFERSISA devices and EISA devices operating in an ISA
compatibility mode can only perform DMA (Direct Memory
Access) to memory below 16 megabytes. This option enables
such devices to work in systems with more than 16
megabytes of memory.options UCONSOLEAllow users to grab the console, useful for X Windows.
For example, you can create a console xterm by typing
xterm -C, which will display any
write, talk, and other messages you receive, as well
as any console messages sent by the kernel.options SYSVSHMThis option provides for System V shared memory. The
most common use of this is the XSHM extension in X
Windows, which many graphics-intensive programs (such as
the movie player XAnim, and Linux DOOM) will automatically
take advantage of for extra speed. If you use the X
Window System, you will definitely want to include
this.options SYSVSEMSupport for System V semaphores. Less commonly used
but only adds a few hundred bytes to the kernel.options SYSVMSGSupport for System V messages. Again, only adds a few
hundred bytes to the kernel.The ipcs1 command will tell
will list any processes using each of these System V
facilities.Filesystem OptionsThese options add support for various filesystems. You must
include at least one of these to support the device you boot from;
typically this will be FFS if you boot from a
hard drive, or NFS if you are booting a
diskless workstation from Ethernet. You can include other
commonly-used filesystems in the kernel, but feel free to comment
out support for filesystems you use less often (perhaps the MS-DOS
filesystem?), since they will be dynamically loaded from the
Loadable Kernel Module directory /lkm the
first time you mount a partition of that type.options FFSThe basic hard drive filesystem; leave it in if you
boot from the hard disk.options NFSNetwork Filesystem. Unless you plan to mount
partitions from a Unix file server over Ethernet, you can
comment this out.options MSDOSFSMS-DOS Filesystem. Unless you plan to mount a DOS
formatted hard drive partition at boot time, you can
safely comment this out. It will be automatically loaded
the first time you mount a DOS partition, as described
above. Also, the excellent mtools software (in the ports
collection) allows you to access DOS floppies without
having to mount and unmount them (and does not require
MSDOSFS at all).options "CD9660"ISO 9660 filesystem for CD-ROMs. Comment it out if
you do not have a CD-ROM drive or only mount data CD's
occasionally (since it will be dynamically loaded the
first time you mount a data CD). Audio CD's do not need
this filesystem.options PROCFSProcess filesystem. This is a pretend filesystem
mounted on /proc which allows
programs like ps1 to give you more
information on what processes are running.options MFSMemory-mapped file system. This is basically a RAM
disk for fast storage of temporary files, useful if you
have a lot of swap space that you want to take advantage
of. A perfect place to mount an MFS partition is on the
/tmp directory, since many programs
store temporary data here. To mount an MFS RAM disk on
/tmp, add the following line to
/etc/fstab and then reboot or type
mount /tmp:
/dev/wd1s2b /tmp mfs rw 0 0Replace the /dev/wd1s2b with
the name of your swap partition, which will be listed in
your /etc/fstab as follows:
/dev/wd1s2b none swap sw 0 0Also, the MFS filesystem can
not be dynamically loaded, so you
must compile it into your kernel if
you want to experiment with it.options "EXT2FS"Linux's native file system. With ext2fs support you
are able to read and write to Linux partitions. This is
useful if you dual-boot FreeBSD and Linux and want to
share data between the two systems.options QUOTAEnable disk quotas. If you have a public access
system, and do not want users to be able to overflow the
/home partition, you can establish
disk quotas for each user. Refer to the
Disk Quotas section for
more information.Basic Controllers and DevicesThese sections describe the basic disk, tape, and CD-ROM
controllers supported by FreeBSD. There are separate sections for
SCSI controllers and network cards.controller isa0All PC's supported by FreeBSD have one of these. If
you have an IBM PS/2 (Micro Channel Architecture), then
you cannot run FreeBSD at this time.controller pci0Include this if you have a PCI motherboard. This
enables auto-detection of PCI cards and gatewaying from
the PCI to the ISA bus.controller fdc0Floppy drive controller: fd0 is the
A: floppy drive, and
fd1 is the B: drive.
ft0 is a QIC-80 tape drive
attached to the floppy controller. Comment out any lines
corresponding to devices you do not have.QIC-80 tape support requires a separate filter
program called ft8, see the manual
page for details.controller wdc0This is the primary IDE controller. wd0 and wd1 are the master and slave hard
drive, respectively. wdc1 is
a secondary IDE controller where you might have a third or
fourth hard drive, or an IDE CD-ROM. Comment out the
lines which do not apply (if you have a SCSI hard drive,
you will probably want to comment out all six lines, for
example).device wcd0This device provides IDE CD-ROM support. Be sure to
leave wdc0 uncommented, and
wdc1 if you have more than
one IDE controller and your CD-ROM is on the second one
card. To use this, you must also include the line
options ATAPI.device npx0 at isa? port "IO_NPX" irq 13
vector npxintrnpx0 is the interface to
the floating point math unit in FreeBSD, either the
hardware co-processor or the software math emulator. It
is not optional.device wt0 at isa? port 0x300 bio irq 5 drq
1 vector wtintrWangtek and Archive QIC-02/QIC-36 tape drive
supportProprietary CD-ROM supportThe following drivers are for the so-called
proprietary CD-ROM drives. These
drives have their own controller card or might plug into a
sound card such as the SoundBlaster 16. They are
not IDE or SCSI. Most older
single-speed and double-speed CD-ROMs use these
interfaces, while newer quad-speeds are likely to be IDE or SCSI.device mcd0 at isa? port 0x300 bio
irq 10 vector mcdintrMitsumi CD-ROM (LU002, LU005, FX001D).device scd0 at isa? port 0x230
bioSony CD-ROM (CDU31, CDU33A).controller matcd0 at isa? port ?
bioMatsushita/Panasonic CD-ROM (sold by Creative
Labs for SoundBlaster).SCSI Device SupportThis section describes the various SCSI controllers and
devices supported by FreeBSD.SCSI ControllersThe next ten or so lines include support for different
kinds of SCSI controllers. Comment out all except for the
one(s) you have:controller bt0 at isa? port
"IO_BT0" bio irq ? vector btintrMost Buslogic controllerscontroller uha0 at isa? port
"IO_UHA0" bio irq ? drq 5 vector uhaintrUltraStor 14F and 34Fcontroller ahc0Adaptec 274x/284x/294xcontroller ahb0 at isa? bio irq ?
vector ahbintrAdaptec 174xcontroller aha0 at isa? port
"IO_AHA0" bio irq ? drq 5 vector ahaintrAdaptec 154xcontroller aic0 at isa? port
0x340 bio irq 11 vector aicintrAdaptec 152x and sound cards using Adaptec
AIC-6360 (slow!)controller nca0 at isa? port
0x1f88 bio irq 10 vector ncaintrProAudioSpectrum cards using NCR 5380 or
Trantor T130controller sea0 at isa? bio irq 5
iomem 0xc8000 iosiz 0x2000 vector seaintrSeagate ST01/02 8 bit controller
(slow!)controller wds0 at isa? port
0x350 bio irq 15 drq 6 vector wdsintrWestern Digital WD7000 controllercontroller ncr0NCR 53C810, 53C815, 53C825, 53C860, 53C875 PCI
SCSI controlleroptions "SCSI_DELAY=15"This causes the kernel to pause 15 seconds before
probing each SCSI device in your system. If you only have
IDE hard drives, you can ignore this, otherwise you will
probably want to lower this number, perhaps to 5 seconds,
to speed up booting. Of course if you do this, and
FreeBSD has trouble recognizing your SCSI devices, you
will have to raise it back up.controller scbus0If you have any SCSI controllers, this line provides
generic SCSI support. If you do not have SCSI, you can
comment this, and the following three lines, out.device sd0Support for SCSI hard drives.device st0Support for SCSI tape drives.device cd0Support for SCSI CD-ROM drives.Note that the number 0
in the above entries is slightly misleading: all these
devices are automatically configured as they are found,
regardless of how many of them are hooked up to the SCSI
bus(es), and which target IDs they have.If you want to “wire down” specific target IDs to
particular devices, refer to the appropriate section of
the LINT kernel config file.Console, Bus Mouse, and X Server SupportYou must choose one of these two console types, and, if you
plan to use the X Window System with the vt220 console, enable the
XSERVER option and optionally, a bus mouse or PS/2 mouse
device.device sc0 at isa? port "IO_KBD" tty irq 1
vector scintrsc0 is the default
console driver, which resembles an SCO console. Since most
full-screen programs access the console through a terminal
database library like termcap, it
should not matter much whether you use this or vt0, the VT220 compatible console
driver. When you log in, set your TERM variable to
“scoansi” if full-screen programs have trouble running
under this console.device vt0 at isa? port "IO_KBD" tty irq 1
vector pcrintThis is a VT220-compatible console driver, backwards
compatible to VT100/102. It works well on some laptops
which have hardware incompatibilities with sc0. Also, set your TERM variable
to vt100 or vt220 when you log in. This driver
might also prove useful when connecting to a large number
of different machines over the network, where the
termcap or
terminfo entries for the sc0 device are often not available
— vt100 should be available on virtually any
platform.options "PCVT_FREEBSD=210"Required with the vt0 console driver.options XSERVEROnly applicable with the vt0 console driver. This
includes code required to run the XFree86 X Window Server
under the vt0
console driver.device mse0 at isa? port 0x23c tty irq 5
vector msUse this device if you have a Logitech or ATI InPort
bus mouse card.If you have a serial mouse, ignore these two lines,
and instead, make sure the appropriate serial port is enabled (probably
COM1).device psm0 at isa? port "IO_KBD"
conflicts tty irq 12 vector psmintrUse this device if your mouse plugs into the PS/2
mouse port.Serial and Parallel PortsNearly all systems have these. If you are attaching a printer
to one of these ports, the Printing section of the handbook is very useful. If
you are using modem, Dialup access provides extensive detail on serial port
configuration for use with such devices.device sio0 at isa? port "IO_COM1" tty irq
4 vector siointrsio0 through sio3 are the four serial ports
referred to as COM1 through COM4 in the MS-DOS world.
Note that if you have an internal modem on COM4 and a
serial port at COM2 you will have to change the IRQ of the
modem to 2 (for obscure technical reasons IRQ 2 = IRQ 9)
in order to access it from FreeBSD. If you have a
multiport serial card, check the manual page for
sio4 for more information on the
proper values for these lines. Some video cards (notably
those based on S3 chips) use IO addresses of the form
0x*2e8, and since many cheap serial
cards do not fully decode the 16-bit IO address space,
they clash with these cards, making the COM4 port
practically unavailable.Each serial port is required to have a unique IRQ
(unless you are using one of the multiport cards where
shared interrupts are supported), so the default IRQs for
COM3 and COM4 cannot be used.device lpt0 at isa? port? tty irq 7 vector
lptintrlpt0 through lpt2 are the three printer ports you
could conceivably have. Most people just have one,
though, so feel free to comment out the other two lines if
you do not have them.NetworkingFreeBSD, as with Unix in general, places a
big emphasis on networking. Therefore, even
if you do not have an Ethernet card, pay attention to the
mandatory options and the dial-up networking support.options INETNetworking support. Leave it in even if you do not
plan to be connected to a network. Most programs require
at least loopback networking (i.e. making network
connections within your PC) so this is essentially
mandatory.Ethernet cardsThe next lines enable support for various Ethernet
cards. If you do not have a network card, you can comment
out all of these lines. Otherwise, you will want to leave
in support for your particular Ethernet card(s):device de0Ethernet adapters based on Digital Equipment
DC21040, DC21041 or DC21140 chipsdevice fxp0Intel EtherExpress Pro/100Bdevice vx03Com 3C590 and 3C595 (buggy)device cx0 at isa? port 0x240 net
irq 15 drq 7 vector cxintrCronyx/Sigma multiport sync/async (with Cisco
or PPP framing)device ed0 at isa? port 0x280 net
irq 5 iomem 0xd8000 vector edintrWestern Digital and SMC 80xx and 8216; Novell
NE1000 and NE2000; 3Com 3C503; HP PC Lan Plus
(HP27247B and HP27252A)device el0 at isa? port 0x300 net
irq 9 vector elintr3Com 3C501 (slow!)device eg0 at isa? port 0x310 net
irq 5 vector egintr3Com 3C505device ep0 at isa? port 0x300 net
irq 10 vector epintr3Com 3C509 (buggy)device fe0 at isa? port 0x240 net
irq ? vector feintrFujitsu MB86960A/MB86965A Ethernetdevice fea0 at isa? net irq ? vector
feaintrDEC DEFEA EISA FDDI adapterdevice ie0 at isa? port 0x360 net
irq 7 iomem 0xd0000 vector ieintrAT&T StarLAN 10 and EN100; 3Com 3C507;
unknown NI5210; Intel EtherExpress 16device le0 at isa? port 0x300 net
irq 5 iomem 0xd0000 vector le_intrDigital Equipment EtherWorks 2 and EtherWorks
3 (DEPCA, DE100, DE101, DE200, DE201, DE202,
DE203, DE204, DE205, DE422)device lnc0 at isa? port 0x300 net
irq 10 drq 0 vector lncintrLance/PCnet cards (Isolan, Novell NE2100,
NE32-VL)device xl03Com Etherlink XL series PCI ethernet
controllers (3C905B and related).device ze0 at isa? port 0x300 net
irq 5 iomem 0xd8000 vector zeintrIBM/National Semiconductor PCMCIA ethernet
controller.device zp0 at isa? port 0x300 net
irq 10 iomem 0xd8000 vector zpintr3Com PCMCIA Etherlink IIIWith certain cards (notably the NE2000) you will
have to change the port and/or IRQ since there is no
“standard” location for these cards.pseudo-device looploop is the generic
loopback device for TCP/IP. If you telnet or FTP to
localhost (a.k.a. 127.0.0.1) it will come back at you
through this pseudo-device. Mandatory.pseudo-device etherether is only needed if
you have an Ethernet card and includes generic Ethernet
protocol code.pseudo-device sl
numbersl is for SLIP (Serial
Line Internet Protocol) support. This has been almost
entirely supplanted by PPP, which is easier to set up,
better suited for modem-to-modem connections, as well as
more powerful. The number after
sl specifies how many
simultaneous SLIP sessions to support. This handbook has
more information on setting up a SLIP client or server.pseudo-device ppp
numberppp is for kernel-mode
PPP (Point-to-Point Protocol) support for dial-up Internet
connections. There is also version of PPP implemented as a
user application that uses the tun and offers more flexibility and
features such as demand dialing. If you still want to use
this PPP driver, read the kernel-mode PPP
section of the handbook. As with the sl device,
number specifies how many
simultaneous PPP connections to support.pseudo-device tun
numbertun is used by the
user-mode PPP software. This program is easy to set up and
very fast. It also has special features such as automatic
dial-on-demand. The number after tun specifies the number of
simultaneous PPP sessions to support. See the user-mode PPP section of the handbook for more
information.pseudo-device bpfilter
numberBerkeley packet filter. This pseudo-device allows
network interfaces to be placed in promiscuous mode,
capturing every packet on a broadcast network (e.g. an
ethernet). These packets can be captured to disk and/or
examined with the tcpdump1 program.
Note that implementation of this capability can seriously
compromise your overall network security. The
number after bpfilter is the number
of interfaces that can be examined simultaneously.
Optional, not recommended except for those who are fully
aware of the potential pitfalls. Not all network cards
support this capability.Sound cardsThis is the first section containing lines that are not in the
GENERIC kernel. To include sound card support, you will have to
copy the appropriate lines from the LINT kernel (which contains
support for every device) as follows:controller snd0Generic sound driver code. Required for all of the
following sound cards except pca.device pas0 at isa? port 0x388 irq 10 drq 6
vector pasintrProAudioSpectrum digital audio and MIDI.device sb0 at isa? port 0x220 irq 7
conflicts drq 1 vector sbintrSoundBlaster digital audio.If your SoundBlaster is on a different IRQ (such as
5), change irq 7 to, for
example, irq 5 and remove
the conflicts keyword.
Also, you must add the line: options
"SBC_IRQ=5"device sbxvi0 at isa? drq 5SoundBlaster 16 digital 16-bit audio.If your SB16 is on a different 16-bit DMA channel
(such as 6 or 7), change the drq
5 keyword appropriately, and then add the
line: options "SB16_DMA=6"device sbmidi0 at isa? port 0x330SoundBlaster 16 MIDI interface. If you have a
SoundBlaster 16, you must include this line, or the kernel
will not compile.device gus0 at isa? port 0x220 irq 10 drq 1
vector gusintrGravis Ultrasound.device mss0 at isa? port 0x530 irq 10 drq 1
vector adintrMicrosoft Sound System.device opl0 at isa? port 0x388
conflictsAdLib FM-synthesis audio. Include this line for
AdLib, SoundBlaster, and ProAudioSpectrum users, if you
want to play MIDI songs with a program such as playmidi (in the ports
collection).device mpu0 at isa? port 0x330 irq 6 drq
0Roland MPU-401 stand-alone card.device uart0 at isa? port 0x330 irq 5 vector
"m6850intr"Stand-alone 6850 UART for MIDI.device pca0 at isa? port "IO_TIMER1"
ttyDigital audio through PC speaker. This is going to be
very poor sound quality and quite CPU-intensive, so you
have been warned (but it does not require a sound
card).There is some additional documentation in
/usr/src/sys/i386/isa/sound/sound.doc.
Also, if you add any of these devices, be sure to create the
sound device nodes.Pseudo-devicesPseudo-device drivers are parts of the kernel that act like
device drivers but do not correspond to any actual hardware in the
machine. The network-related pseudo-devices are in that section,
while the remainder are here.pseudo-device gzipgzip allows you to run
FreeBSD programs that have been compressed with gzip. The programs in
/stand are compressed so it is a good
idea to have this option in your kernel.pseudo-device loglog is used for logging
of kernel error messages. Mandatory.pseudo-device pty
numberpty is a
“pseudo-terminal” or simulated login port. It is used
by incoming telnet and
rlogin sessions, xterm, and
some other applications such as emacs. The
number indicates the number of
ptys to create. If you need
more than GENERIC default of 16 simultaneous xterm windows
and/or remote logins, be sure to increase this number
accordingly, up to a maximum of 256.pseudo-device snp
numberSnoop device. This pseudo-device allows one terminal
session to watch another using the
watch8 command. Note that
implementation of this capability has important security
and privacy implications. The number
after snp is the total number of simultaneous snoop
sessions. Optional.pseudo-device vnVnode driver. Allows a file to be treated as a device
after being set up with the vnconfig8
command. This driver can be useful for manipulating
floppy disk images and using a file as a swap device (e.g.
an MS Windows swap file). Optional.pseudo-device ccd
numberConcatenated disks. This pseudo-device allows you to
concatenate multiple disk partitions into one large
“meta”-disk. The number after ccd
is the total number of concatenated disks (not total
number of disks that can be concatenated) that can be
created. (See ccd4 and
ccdconfig8 man pages for more
details.) Optional.Joystick, PC Speaker, MiscellaneousThis section describes some miscellaneous hardware devices
supported by FreeBSD. Note that none of these lines are included
in the GENERIC kernel, you will have to copy them from this
handbook or the LINT kernel (which contains support for
every device):device joy0 at isa? port "IO_GAME"PC joystick device.pseudo-device speakerSupports IBM BASIC-style noises through the PC
speaker. Some fun programs which use this are
/usr/sbin/spkrtest, which is a shell
script that plays some simple songs, and
/usr/games/piano which lets you play
songs using the keyboard as a simple piano (this file only
exists if you have installed the
games package). Also, the excellent
text role-playing game NetHack (in the ports collection)
can be configured to use this device to play songs when
you play musical instruments in the game.See also the pca0 device.Making Device NodesAlmost every device in the kernel has a corresponding “node”
entry in the /dev directory. These nodes look
like regular files, but are actually special entries into the kernel
which programs use to access the device. The shell script
/dev/MAKEDEV, which is executed when you first
install the operating system, creates nearly all of the device nodes
supported. However, it does not create all of
them, so when you add support for a new device, it pays to make sure
that the appropriate entries are in this directory, and if not, add
them. Here is a simple example:Suppose you add the IDE CD-ROM support to the kernel. The line
to add is:
controller wcd0This means that you should look for some entries
that start with wcd0 in the
/dev directory, possibly followed by a letter,
such as c, or preceded by the letter r, which means a “raw”
device. It turns out that those files are not there, so I must
change to the /dev directory and type:&prompt.root; sh MAKEDEV wcd0When this script finishes, you will find that
there are now wcd0c and rwcd0c entries in /dev so
you know that it executed correctly.For sound cards, the command:
&prompt.root; sh MAKEDEV snd0 creates the appropriate entries.When creating device nodes for devices such as sound cards, if
other people have access to your machine, it may be desirable to
protect the devices from outside access by adding them to the
/etc/fbtab file. See man
fbtab for more information.Follow this simple procedure for any other non-GENERIC devices
which do not have entries.All SCSI controllers use the same set of
/dev entries, so you do not need to create
these. Also, network cards and SLIP/PPP pseudo-devices do not
have entries in /dev at all, so you do not
have to worry about these either.If Something Goes WrongThere are four categories of trouble that can occur when
building a custom kernel. They are:Config command failsIf the config command
fails when you give it your kernel description, you have
probably made a simple error somewhere. Fortunately,
config will print the line
number that it had trouble with, so you can quickly skip to
it with vi. For example, if
you see:
config: line 17: syntax error you can skip to the problem in vi by typing 17G in command mode.
Make sure the keyword is typed correctly, by comparing it to
the GENERIC kernel or another reference.Make command failsIf the make command fails,
it usually signals an error in your kernel description, but
not severe enough for config
to catch it. Again, look over your configuration, and if
you still cannot resolve the problem, send mail to the
&a.questions; with your kernel configuration, and it should
be diagnosed very quickly.Kernel will not bootIf your new kernel does not boot, or fails to recognize
your devices, do not panic! Fortunately, BSD has an
excellent mechanism for recovering from incompatible
kernels. Simply type the name of the kernel you want to boot
from (i.e. kernel.old) at the FreeBSD boot prompt
instead of pressing return. When reconfiguring a kernel, it
is always a good idea to keep a kernel that is known to work
on hand.After booting with a good kernel you can check over your
configuration file and try to build it again. One helpful
resource is the /var/log/messages file
which records, among other things, all of the kernel
messages from every successful boot. Also, the
dmesg8 command will print the kernel
messages from the current boot.If you are having trouble building a kernel, make sure
to keep a GENERIC, or some other kernel that is known to
work on hand as a different name that will not get erased
on the next build. You cannot rely on
kernel.old because when installing a
new kernel, kernel.old is overwritten
with the last installed kernel which may be
non-functional. Also, as soon as possible, move the
working kernel to the proper kernel location or
commands such as ps1 will not work
properly. The proper command to “unlock” the
kernel file that make installs (in
order to move another kernel back permanently) is:&prompt.root; chflags noschg /kernelAnd, if you want to
“lock” your new kernel into place, or any
file for that matter, so that it cannot be moved or
tampered with:&prompt.root; chflags schg /kernelKernel works, but ps does not work any more!If you have installed a different version of the kernel
from the one that the system utilities have been built with,
for example, an experimental “2.2.0” kernel on a
2.1.0-RELEASE system, many system-status commands like
ps1 and vmstat8
will not work any more. You must recompile the libkvm library as well as these
utilities. This is one reason it is not normally a good
idea to use a different version of the kernel from the rest
of the operating system.
diff --git a/en/handbook/linuxemu/chapter.sgml b/en/handbook/linuxemu/chapter.sgml
index 0e2bc3b76d..044c736cf4 100644
--- a/en/handbook/linuxemu/chapter.sgml
+++ b/en/handbook/linuxemu/chapter.sgml
@@ -1,860 +1,860 @@
Linux EmulationContributed by &a.handy; and &a.rich;How to Install the Linux EmulatorLinux emulation in FreeBSD has reached a point where it is
possible to run a large fraction of Linux binaries in both a.out and
ELF format. The linux emulation in the 2.1-STABLE branch is capable
of running Linux DOOM and Mathematica; the version present in
&rel.current;-RELEASE is vastly more capable and runs all these as
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
other programs.There are some Linux-specific operating system features that are
not supported on FreeBSD. Linux binaries will not work on FreeBSD
if they use the Linux /proc filesystem (which
is different from the optional FreeBSD /proc
filesystem) or i386-specific calls, such as enabling virtual 8086
mode.Depending on which version of FreeBSD you are running, how you
get Linux-emulation up will vary slightly:Installing Linux Emulation in 2.1-STABLEThe GENERIC kernel in 2.1-STABLE is not
configured for linux compatibility so you must reconfigure your
kernel for it. There are two ways to do this: 1. linking the
emulator statically in the kernel itself and 2. configuring your
kernel to dynamically load the linux loadable kernel module
(LKM).To enable the emulator, add the following to your
configuration file (c.f.
/sys/i386/conf/LINT):
options COMPAT_LINUXIf you want to run doom or other applications
that need shared memory, also add the following.
options SYSVSHMThe linux system calls require 4.3BSD system
call compatibility. So make sure you have the following.
options "COMPAT_43"If you prefer to statically link the emulator in the kernel
rather than use the loadable kernel module (LKM), then add
options LINUXThen run config and install the new kernel as
described in the
kernel configuration
section.If you decide to use the LKM you must also install the
loadable module. A mismatch of versions between the kernel and
loadable module can cause the kernel to crash, so the safest thing
to do is to reinstall the LKM when you install the kernel.&prompt.root; cd /usr/src/lkm/linux
&prompt.root; make all installOnce you have installed the kernel and the LKM,
you can invoke `linux' as root to load the LKM.&prompt.root; linux
Linux emulator installed
Module loaded as ID 0To see whether the LKM is loaded, run
modstat.&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulatorYou can cause the LKM to be loaded when the
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
2.1-STABLE enable it in /etc/sysconfig
linux=YES by changing it from NO to YES. FreeBSD 2.1
RELEASE and earlier do not have such a line and on those you will
need to edit /etc/rc.local to add the following line.
linuxInstalling Linux Emulation in 2.2.2-RELEASE and laterIt is no longer necessary to specify options LINUX or
options COMPAT_LINUX. Linux emulation is done with an LKM
(“Loadable Kernel Module”) so it can be installed on the fly
without having to reboot. You will need the following things in
your startup files, however:In /etc/rc.conf, you need the
following line:
linux_enable=YESThis, in turn, triggers the following action in
/etc/rc.i386:
# Start the Linux binary emulation if requested.
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
linux'; linux > /dev/null 2>&1
fiIf you want to verify it is running, modstat will do that:&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 4 f09e6000 001c f09ec010 1 linux_modHowever, there have been reports that this
fails on some 2.2-RELEASE and later systems. If for some reason
you cannot load the linux LKM, then statically link the emulator
in the kernel by adding
options LINUX
to your kernel config file. Then run config
and install the new kernel as described in the kernel configuration section.Installing Linux Runtime LibrariesInstalling using the linux_lib portMost linux applications use shared libraries, so you are
still not done until you install the shared libraries. It is
possible to do this by hand, however, it is vastly simpler to
just grab the linux_lib port:&prompt.root; cd /usr/ports/emulators/linux_lib
&prompt.root; make all installand you should have a working linux emulator. Legend (and
the mail archives :-) seems to hold that Linux emulation works
best with linux binaries linked against the ZMAGIC libraries;
QMAGIC libraries (such as those used in Slackware V2.0) may tend
to give the Linuxulator heartburn. Also, expect some programs to complain
about incorrect minor versions of the system libraries. In
general, however, this does not seem
to be a problem.Installing libraries manuallyIf you do not have the “ports” distribution, you can
install the libraries by hand instead. You will need the Linux
shared libraries that the program depends on and the runtime
linker. Also, you will need to create a "shadow root"
directory, /compat/linux, for Linux
libraries on your FreeBSD system. Any shared libraries opened
by Linux programs run under FreeBSD will look in this tree
first. So, if a Linux program loads, for example,
/lib/libc.so, FreeBSD will first try to
open /compat/linux/lib/libc.so, and if that
does not exist then it will try
/lib/libc.so. Shared libraries should be
installed in the shadow tree
/compat/linux/lib rather than the paths
that the Linux ld.so reports.FreeBSD-2.2-RELEASE and later works slightly differently
with respect to /compat/linux: all files, not just
libraries, are searched for from the “shadow root”
/compat/linux.Generally, you will need to look for the shared libraries
that Linux binaries depend on only the first few times that you
install a Linux program on your FreeBSD system. After a while,
you will have a sufficient set of Linux shared libraries on your
system to be able to run newly imported Linux binaries without
any extra work.How to install additional shared librariesWhat if you install the linux_lib port and your application
still complains about missing shared libraries? How do you know
which shared libraries Linux binaries need, and where to get
them? Basically, there are 2 possibilities (when following these
instructions: you will need to be root on your FreeBSD system to
do the necessary installation steps).If you have access to a Linux system, see what shared
libraries the application needs, and copy them to your FreeBSD system.
Example: you have just ftp'ed the Linux binary of Doom. Put it
on the Linux system you have access to, and check which shared
libraries it needs by running ldd linuxxdoom:&prompt.user; ldd linuxxdoom
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29You would need to get all the files from the last column,
and put them under /compat/linux, with the
names in the first column as symbolic links pointing to them.
This means you eventually have these files on your FreeBSD
system:/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29Note that if you already have a Linux shared library with
a matching major revision number to the first column of the
ldd output, you will not need to copy the file named in the
last column to your system, the one you already have should
work. It is advisable to copy the shared library anyway if it
is a newer version, though. You can remove the old one, as
long as you make the symbolic link point to the new one. So,
if you have these libraries on your system:/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27and you find a new binary that claims to require a later
version according to the output of ldd:libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29If it is only one or two versions out of date in the in
the trailing digit then do not worry about copying
/lib/libc.so.4.6.29 too, because the
program should work fine with the slightly older version.
However, if you like you can decide to replace the
libc.so anyway, and that should leave you
with:/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29The symbolic link mechanism is only
needed for Linux binaries. The FreeBSD runtime linker takes
care of looking for matching major revision numbers itself and
you do not need to worry about it.Configuring the ld.so — for FreeBSD
2.2-RELEASE and laterThis section applies only to FreeBSD 2.2-RELEASE and later.
Those running 2.1-STABLE should skip this section.Finally, if you run FreeBSD 2.2-RELEASE you must make sure
that you have the Linux runtime linker and its config files on
your system. You should copy these files from the Linux system
to their appropriate place on your FreeBSD system (to the
/compat/linux tree):/compat/linux/lib/ld.so
/compat/linux/etc/ld.so.configIf you do not have access to a Linux system, you should get
the extra files you need from various ftp sites. Information on
where to look for the various files is appended below. For now,
let us assume you know where to get the files.Retrieve the following files (all from the same ftp site to
avoid any version mismatches), and install them under
/compat/linux (i.e.
/foo/bar is installed as
/compat/linux/foo/bar):/sbin/ldconfig
/usr/bin/ldd
/lib/libc.so.x.y.z
/lib/ld.soldconfig and ldd do not necessarily need to be under
/compat/linux; you can install them
elsewhere in the system too. Just make sure they do not conflict
with their FreeBSD counterparts. A good idea would be to install
them in /usr/local/bin as ldconfig-linux
and ldd-linux.Create the file
/compat/linux/etc/ld.so.conf, containing
the directories in which the Linux runtime linker should look
for shared libs. It is a plain text file, containing a directory
name on each line. /lib and
/usr/lib are standard, you could add the
following:
/usr/X11/lib
/usr/local/libWhen a linux binary opens a library such as
/lib/libc.so the emulator maps the name to
/compat/linux/lib/libc.so internally. All
linux libraries should be installed under /compat/linux (e.g.
/compat/linux/lib/libc.so,
/compat/linux/usr/X11/lib/libX11.so, etc.)
in order for the emulator to find them.Those running FreeBSD 2.2-RELEASE should run the Linux
ldconfig program.&prompt.root cd /compat/linux/lib
&prompt.root; /compat/linux/sbin/ldconfigldconfig is statically linked, so it does not need any
shared libraries to run. It creates the file
/compat/linux/etc/ld.so.cache which
contains the names of all the shared libraries and should be
rerun to recreate this file whenever you install additional
shared libraries.On 2.1-STABLE do not install
/compat/linux/etc/ld.so.cache or run
ldconfig; in 2.1-STABLE the syscalls are implemented differently
and ldconfig is not needed or used.You should now be set up for Linux binaries which only need
a shared libc. You can test this by running the Linux ldd on
itself. Supposing that you have it installed as ldd-linux, it
should produce something like:&prompt.root; ldd-linux `which ldd-linux`
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29This being done, you are ready to install new Linux
binaries. Whenever you install a new Linux program, you should
check if it needs shared libraries, and if so, whether you have
them installed in the /compat/linux tree.
To do this, you run the Linux version ldd on the new program,
and watch its output. ldd (see also the manual page for ldd1)
will print a list of shared libraries that the program depends
on, in the form majorname (jumpversion) => fullname.If it prints not found instead of fullname it means that
you need an extra library. The library needed is shown in
majorname and will be of the form libXXXX.so.N. You will need to
find a libXXXX.so.N.mm on a Linux ftp site, and install it on
your system. The XXXX (name) and N (major revision number)
should match; the minor number(s) mm are less important, though
it is advised to take the most recent version.Installing Linux ELF binariesELF binaries sometimes require an extra step of
“branding”. If you attempt to run an unbranded ELF binary,
you will get an error message like the following;&prompt.user; ./my-linux-elf-binary
ELF binary type not known
AbortTo help the FreeBSD kernel distinguish between a FreeBSD ELF
- binary from a Linux one, use the
+ binary from a Linux binary, use the brandelf1 utility.&prompt.user; brandelf -t Linux my-linux-elf-binaryThe GNU toolchain now places the appropriate branding information
into ELF binaries automatically, so you should be needing to do this
step increasingly rarely in future.Configuring the host name resolverIf DNS does not work or you get the messages
resolv+: "bind" is an invalid keyword resolv+:
"hosts" is an invalid keyword
then you need to configure a
/compat/linux/etc/host.conf file containing:
order hosts, bind
multi on
where the order here specifies that
/etc/hosts is searched first and DNS is
searched second. When
/compat/linux/etc/host.conf is not installed
linux applications find FreeBSD's
/etc/host.conf and complain about the
incompatible FreeBSD syntax. You should remove bind if you
have not configured a name-server using the
/etc/resolv.conf file.Lastly, those who run 2.1-STABLE need to set an the
RESOLV_HOST_CONF environment variable so that applications will
know how to search the host tables. If you run FreeBSD
2.2-RELEASE or later, you can skip this. For the
/bin/csh shell use:&prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.confFor /bin/sh use:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFFinding the necessary filesThe information below is valid as of the time this document
was written, but certain details such as names of ftp sites,
directories and distribution names may have changed by the time
you read this.Linux is distributed by several groups that make their own set
of binaries that they distribute. Each distribution has its own
name, like “Slackware” or “Yggdrasil”. The distributions are
available on a lot of ftp sites. Sometimes the files are unpacked,
and you can get the individual files you need, but mostly they are
stored in distribution sets, usually consisting of subdirectories
with gzipped tar files in them. The primary ftp sites for the
distributions are:sunsite.unc.edu:/pub/Linux/distributionstsx-11.mit.edu:/pub/linux/distributionsSome European mirrors:ftp.luth.se:/pub/linux/distributionsftp.demon.co.uk:/pub/unix/linuxsrc.doc.ic.ac.uk:/packages/linux/distributionsFor simplicity, let us concentrate on Slackware here. This
distribution consists of a number of subdirectories, containing
separate packages. Normally, they are controlled by an install
program, but you can retrieve files “by hand” too. First of all,
you will need to look in the contents subdir of the
distribution. You will find a lot of small text files here
describing the contents of the separate packages. The fastest way
to look something up is to retrieve all the files in the contents
subdirectory, and grep through them for the file you need. Here is
an example of a list of files that you might need, and in which
contents-file you will find it by grepping through them:LibraryPackageld.soldso
ldconfigldso lddldso
libc.so.4shlibs libX11.so.6.0xf_lib
libXt.so.6.0xf_lib
libX11.so.3oldlibs
libXt.so.3oldlibs
So, in this case, you will need the packages ldso, shlibs,
xf_lib and oldlibs. In each of the contents-files for these
packages, look for a line saying PACKAGE LOCATION, it will
tell you on which “disk” the package is, in our case it will tell
us in which subdirectory we need to look. For our example, we
would find the following locations:PackageLocationldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 The locations called “diskXX” refer to the slakware/XX
subdirectories of the distribution, others may be found in the
contrib subdirectory. In this case, we
could now retrieve the packages we need by retrieving the
following files (relative to the root of the Slackware
distribution tree):slakware/a2/ldso.tgzslakware/a2/shlibs.tgzslakware/x6/oldlibs/tgzslakware/x9/xf_lib.tgzExtract the files from these gzipped tarfiles in your
/compat/linux directory (possibly omitting or
afterwards removing files you do not need), and you are
done.See also:ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README and /usr/src/sys/i386/ibcs2/README.iBCS2How to Install Mathematica on FreeBSDContributed by &a.rich; and
&a.chuck;This document shows how to install the Linux binary distribution
of Mathematica 2.2 on FreeBSD 2.1.Mathematica supports Linux but not FreeBSD as it stands. So
once you have configured your system for Linux compatibility you
have most of what you need to run Mathematica.For those who already have the student edition of Mathematica
for DOS the cost of upgrading to the Linux version at the time this
was written, March 1996, was $45.00. It can be ordered directly
from Wolfram at (217) 398-6500 and paid for by credit card.Unpacking the Mathematica distributionThe binaries are currently distributed by Wolfram on CDROM.
The CDROM has about a dozen tar files, each of which is a binary
distribution for one of the supported architectures. The one for
Linux is named LINUX.TAR. You can, for
example, unpack this into
/usr/local/Mathematica:&prompt.root; cd /usr/local
&prompt.root; mkdir Mathematica
&prompt.root; cd Mathematica
&prompt.root; tar -xvf /cdrom/LINUX.TARObtaining your Mathematica PasswordBefore you can run Mathematica you will have to obtain a
password from Wolfram that corresponds to your “machine
ID”.Once you have installed the linux compatibility runtime
libraries and unpacked the mathematica you can obtain the “machine
ID” by running the program mathinfo in the Install directory.&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; mathinfo
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
richc.isdn.bcm.tmc.edu 9845-03452-90255So, for example, the “machine ID” of richc is
9845-03452-90255. You can ignore the message about the ioctl
that is not implemented. It will not prevent Mathematica from
running in any way and you can safely ignore it, though you will
see the message every time you run Mathematica.When you register with Wolfram, either by email, phone or fax,
you will give them the “machine ID” and they will respond with a
corresponding password consisting of groups of numbers. You need
to add them both along with the machine name and license number in
your mathpass file.You can do this by invoking:&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; math.installIt will ask you to enter your license number
and the Wolfram supplied password. If you get them mixed up or
for some reason the math.install fails, that is OK; you can simply
edit the file mathpass in this same directory to correct the
info manually.After getting past the password, math.install will ask you if
you accept the install defaults provided, or if you want to use
your own. If you are like us and distrust all install programs,
you probably want to specify the actual directories. Beware.
Although the math.install program asks you to specify directories,
it will not create them for you, so you should perhaps have a
second window open with another shell so that you can create them
before you give them to the install program. Or, if it fails, you
can create the directories and then restart the math.install
program. The directories we chose to create beforehand and
specify to math.install were:/usr/local/Mathematica/binfor binaries/usr/local/Mathematica/man/man1for man pages/usr/local/Mathematica/lib/X11for the XKeysymb fileYou can also tell it to use
/tmp/math.record for the system record file,
where it puts logs of sessions. After this math.install will
continue on to unpacking things and placing everything where it
should go.The Mathematica Notebook feature is included separately, as
the X Front End, and you have to install it separately. To get the
X Front End stuff correctly installed, cd into the
/usr/local/Mathematica/FrontEnd directory and
execute the xfe.install shell script. You will have to tell it
where to put things, but you do not have to create any directories
because it will use the same directories that had been created for
math.install. When it finishes, there should be a new shell script
in /usr/local/Mathematica/bin called
mathematica.Lastly, you need to modify each of the shell scripts that
Mathematica has installed. At the beginning of every shell script
in /usr/local/Mathematica/bin add the
following line:&prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDBThis tells Mathematica were to find its own
version of the key mapping file XKeysymDB.
Without this you will get pages of error messages about missing
key mappings.On 2.1-STABLE you need to add the following as well:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFThis tells Mathematica to use the linux version
of host.conf. This file has a different syntax from FreeBSD's
host.conf, so you will get an error message about
/etc/host.conf if you leave this out.You might also want to modify your
/etc/manpath.config file to read the new man
directory, and you may need to edit your
~/.cshrc file to add
/usr/local/Mathematica/bin to your
path.That is about all it takes. With this you should be able to
type mathematica and get a really slick looking Mathematica
Notebook screen up. Mathematica has included the Motif user
interfaces, but it is compiled in statically, so you do not need
the Motif libraries. Good luck doing this yourself!BugsThe Notebook front end is known to hang sometimes when reading
notebook files with an error messages similar to:File .../Untitled-1.mb appears to be broken for OMPR.257.0We have not found the cause for this, but it only affects the
Notebook's X Window front end, not the mathematica engine itself.
So the command line interface invoked by 'math' is unaffected by
this bug.AcknowledgmentsA well-deserved thanks should go to &a.sos; and &a.peter; who
made linux emulation what it is today, and Michael Smith who drove
these two guys like dogs to get it to the point where it runs
Linux binaries better than linux! :-)
diff --git a/en/handbook/mail/chapter.sgml b/en/handbook/mail/chapter.sgml
index 18b2d73610..189309586a 100644
--- a/en/handbook/mail/chapter.sgml
+++ b/en/handbook/mail/chapter.sgml
@@ -1,593 +1,593 @@
Electronic MailContributed by &a.wlloyd;.Electronic Mail configuration is the subject of many System Administration books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.Some parts of E-Mail configuration are controlled in the Domain
Name System (DNS). If you are going to run your own own DNS server
check out /etc/namedb and man -k named for more information.Basic InformationThese are the major programs involved in an E-Mail exchange. A
“mailhost” is a server that is
responsible for delivering and receiving all email for your host,
and possibly your network.User programThis is a program like elm, pine,
mail, or something more sophisticated like a WWW
browser. This program will simply pass off all e-mail
transactions to the local “mailhost” ,
either by calling sendmail or
delivering it over TCP.Mailhost Server DaemonUsually this program is sendmail or
smail running in the background. Turn it off or
change the command line options in
/etc/rc.conf (or, prior to FreeBSD 2.2.2,
/etc/sysconfig). It is best to leave it on,
unless you have a specific reason to want it off. Example: You
are building a Firewall.You should be aware that sendmail is a potential weak link in a
secure site. Some versions of sendmail have known security
problems.sendmail does two jobs. It looks after delivering
and receiving mail.If sendmail
needs to deliver mail off your site it will look up in
the DNS to determine the actual host that will receive mail for
the destination.If it is acting as a delivery agent sendmail will take the message from the
local queue and deliver it across the Internet to another sendmail
on the receivers computer.DNS — Name ServiceThe Domain Name System and its daemon named, contain the database mapping
hostname to IP address, and hostname to mailhost. The IP address
is specified in an A record. The MX record specifies the
mailhost that will receive mail for you. If you do not have a
MX record mail for your hostname, the mail will be delivered to
your host directly.Unless you are running your own DNS server, you will not be
able to change any information in the DNS yourself. If you are
using an Internet Provider, speak to them.POP ServersThis program gets the mail from your mailbox and gives it to
your browser. If you want to run a POP server on your computer,
you will need to do 2 things.Get pop software from the Ports collection that
can be found in /usr/ports or packages
collection. This handbook section has a complete reference
on the Ports system.Modify /etc/inetd.conf
to load the POP server.The pop program will have instructions with it. Read
them.ConfigurationBasicAs your FreeBSD system comes “out of the box”[TM], you should
be able to send E-mail to external hosts as long as you have
/etc/resolv.conf setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods:Run a name server (man -k named) and have your own domain
smallminingco.com Get mail delivered to the current DNS name for your host.
Ie: dorm6.ahouse.school.edu No matter what option you choose, to have mail delivered
directly to your host, you must be a full Internet host. You must
have a permanent IP address. IE: NO dynamic PPP. If you are
behind a firewall, the firewall must be passing on smtp traffic to
you. From /etc/services:smtp 25/tcp mail #Simple Mail TransferIf you
want to receive mail at your host itself, you must make sure that
the DNS MX entry points to your host address, or there is no MX
entry for your DNS name.Try this:&prompt.root; hostname
newbsdbox.freebsd.org
&prompt.root; host newbsdbox.freebsd.org
newbsdbox.freebsd.org has address 204.216.27.xxIf that is all that comes out for your machine, mail directory
to root@newbsdbox.freebsd.org
will work no problems.If instead, you have this:&prompt.root; host newbsdbox.freebsd.org
newbsdbox.FreeBSD.org has address 204.216.27.xx
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.orgAll mail sent to your host
directly will end up on freefall, under the same username.This information is setup in your domain name server. This
should be the same host that is listed as your primary nameserver
in /etc/resolv.confThe DNS record that carries mail routing information is the
Mail eXchange entry. If no MX entry exists, mail will be
delivered directly to the host by way of the Address
record.The MX entry for freefall.freebsd.org at one time.
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall HINFO Pentium FreeBSD
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com
freefall A 204.216.27.xx
freefall CNAME www.FreeBSD.orgfreefall has many MX entries. The lowest MX number gets the
mail in the end. The others will queue mail temporarily, if
freefall is busy or down.Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other
friendly site can provide this service.dig, nslookup,
and host are your friends.Mail for your Domain (Network).To setup up a network mailhost, you need to direct the mail
from arriving at all the workstations. In other words, you want to
hijack all mail for *.smallminingco.com
and divert it to one machine, your “mailhost”.The network users on their workstations will most likely pick
up their mail over POP or telnet.A user account with the same username should exist on both
machines. Please use adduser to do
this as required. If you set the shell to
/nonexistent
the user will not be allowed to login.The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS
(ie BIND, named). Please refer to a Networking book for in-depth
information.You basically need to add these lines in your DNS server.
pc24.smallminingco.com A xxx.xxx.xxx.xxx ; Workstation ip
MX 10 smtp.smallminingco.com ; Your mailhostYou cannot do this yourself unless you are running a DNS
server. If you do not want to run a DNS server, get somebody else
like your Internet Provider to do it.This will redirect mail for the workstation to the Mail
eXchange host. It does not matter what machine the A record
points to, the mail will be sent to the MX host.This feature is used to implement Virtual E-Mail Hosting.ExampleI have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make
an entry in your DNS server like:
foo.bar MX 10 smtp.smalliap.com ; your mailhostThe A record is not needed if you only
want E-Mail for the domain. IE: Don't expect ping foo.bar
to work unless an Address record for foo.bar
exists as well.On the mailhost that actually accepts mail for final delivery
to a mailbox, sendmail must be told what hosts it will be
accepting mail for.Add pc24.smallminingco.com to /etc/sendmail.cw (if you are
using FEATURE(use_cw_file)), or add a Cw myhost.smalliap.com
line to /etc/sendmail.cfIf you plan on doing anything serious with sendmail you should install the sendmail
source. The source has plenty of documentation with it. You will
find information on getting sendmail
source from the UUCP
information.Setting up UUCP.Stolen from the FAQ.The sendmail configuration that ships with FreeBSD is suited
for sites that connect directly to the Internet. Sites that wish
to exchange their mail via UUCP must install another sendmail
configuration file.Tweaking /etc/sendmail.cf manually is
considered something for purists. Sendmail version 8 comes with a
new approach of generating config files via some m4 preprocessing, where the actual
hand-crafted configuration is on a higher abstraction level. You
should use the configuration files under
/usr/src/usr.sbin/sendmail/cf.If you did not install your system with full sources, the
sendmail config stuff has been broken out into a separate source
distribution tarball just for you. Assuming you have your CD-ROM
mounted, do:&prompt.root; cd /usr/src
&prompt.root; tar -xvzf /cdrom/dists/src/ssmailcf.aaDo not panic, this is only a few hundred kilobytes in size.
The file README in the cf directory can serve as a basic
introduction to m4 configuration.For UUCP delivery, you are best advised to use the
mailertable feature. This constitutes a
database that sendmail can use to base its routing decision
upon.First, you have to create your .mc file.
The directory
/usr/src/usr.sbin/sendmail/cf/cf is the home
of these files. Look around, there are already a few examples.
Assuming you have named your file foo.mc, all
you need to do in order to convert it into a valid
sendmail.cf is:&prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf
&prompt.root; make foo.cfIf you don't have a /usr/obj hiearchy,
then:&prompt.root; cp foo.cf /etc/sendmail.cfOtherwise:&prompt.root; cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cfA typical .mc file might look
like:
include(`../m4/cf.m4')
VERSIONID(`Your version number')
OSTYPE(bsd4.4)
FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)
define(`UUCP_RELAY', your.uucp.relay)
define(`UUCP_MAX_SIZE', 200000)
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw your.alias.host.name
Cw youruucpnodename.UUCPThe nodns and
nocanonify features will prevent any usage of
the DNS during mail delivery. The UUCP_RELAY
clause is needed for bizarre reasons, do not ask. Simply put an
Internet hostname there that is able to handle .UUCP pseudo-domain
addresses; most likely, you will enter the mail relay of your ISP
there.Once you have this, you need this file called
/etc/mailertable. A typical example of this
gender again:
#
# makemap hash /etc/mailertable.db < /etc/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1 horus.UUCP
uucp-dom:horus if-bus.UUCP
uucp-dom:if-bus . uucp-dom:saxAs you can see, this is part of a real-life file. The first
three lines handle special cases where domain-addressed mail
should not be sent out to the default route, but instead to some
UUCP neighbor in order to “shortcut” the delivery path. The
next line handles mail to the local Ethernet domain that can be
delivered using SMTP. Finally, the UUCP neighbors are mentioned
in the .UUCP pseudo-domain notation, to allow for a
uucp-neighbor!recipient override of the default rules. The
last line is always a single dot, matching everything else, with
UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
uucp-dom: keyword must be valid UUCP
neighbors, as you can verify using the command uuname.As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish
this is best placed as a comment at the top of the mailertable.
You always have to execute this command each time you change your
mailertable.Final hint: if you are uncertain whether some particular mail
routing would work, remember the option to
sendmail. It starts sendmail
in “address test
mode”; simply enter 0, followed by the address
you wish to test for the mail routing. The last line tells you
the used internal mail agent, the destination host this agent will
be called with, and the (possibly translated) address. Leave this
mode by typing Control-D.&prompt.user; sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>0 foo@interface-business.de
rewrite: ruleset 0 input: foo @ interface-business . de
…
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . deFAQMigration from FAQ.Why do I have to use the FQDN for hosts on my site?You will probably find that the host is actually in a
different domain; for example, if you are in foo.bar.edu and you
wish to reach a host called mumble in the bar.edu domain, you
will have to refer to it by the fully-qualified domain name,
mumble.bar.edu, instead of just mumble.Traditionally, this was allowed by BSD BIND resolvers. However
the current version of BIND that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host mumble must either
be found as mumble.foo.bar.edu, or
it will be searched for in the root domain.This is different from the previous behavior, where the search
continued across mumble.bar.edu,
and mumble.edu. Have a look at
RFC 1535 for why this was considered bad practice, or even a
security hole.As a good workaround, you can place the line
search foo.bar.edu bar.edu
instead of the previous
domain foo.bar.edu
into your /etc/resolv.conf. However,
make sure that the search order does not go beyond the “boundary
between local and public administration”, as RFC 1535 calls
it.Sendmail says mail loops back to myselfThis is answered in the sendmail FAQ as follows:
* I am getting "Local configuration error" messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 <user@domain.net>... Local configuration error
How can I solve this problem?
You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine does not recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
to /etc/sendmail.cf.The sendmail FAQ is in
/usr/src/usr.sbin/sendmail and is recommended
reading if you want to do any “tweaking” of your mail
setup.How can I do E-Mail with a dialup PPP host?You want to connect a FreeBSD box on a lan, to the Internet.
The FreeBSD box will be a mail gateway for the lan. The PPP
connection is non-dedicated.There are at least two way to do this.The other is to use UUCP.The key is to get a Internet site to provide secondary MX
services for your domain. For example:
bigco.com. MX 10 bigco.com.
MX 20 smalliap.com.Only one host should be specified as the final recipient ( add
Cw bigco.com in /etc/sendmail.cf on
bigco.com).When the senders sendmail is trying to deliver the mail it
will try to connect to you over the modem link. It will most
likely time out because you are not online. sendmail will
automatically deliver it to the secondary MX site, ie your
Internet provider. The secondary MX site will try every
(sendmail_flags = "-bd -q15m" in
/etc/rc.conf ) 15 minutes to connect to your
host to deliver the mail to the primary MX site.
- You might wat to use something like this as a login script.
+ You might want to use something like this as a login script.
#!/bin/sh
# Put me in /usr/local/bin/pppbigco
( sleep 60 ; /usr/sbin/sendmail -q ) &
/usr/sbin/ppp -direct pppbigcoIf you are going to create a separate
login script for a user you could use sendmail
-qRbigco.com instead in the script above. This will
force all mail in your queue for bigco.com to be processed
immediately.A further refinement of the situation is as follows.Message stolen from the freebsd-isp mailing list.
> we provide the secondary mx for a customer. The customer connects to
> our services several times a day automatically to get the mails to
> his primary mx (We do not call his site when a mail for his domains
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
> moment he has to stay 30 minutes online to be sure that all mail is
> gone to the primary mx.
>
> Is there a command that would initiate sendmail to send all the mails
> now? The user has not root-privileges on our machine of course.
In the 'privacy flags' section of sendmail.cf, there is a definition
Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
customers like this, and we have defined:
# If we are the best MX for a host, try directly instead of generating
# local config error.
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
"hosts", so you need to get your customer to name their mail machine
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
an A record in the DNS for "customer.com".
diff --git a/en/handbook/mirrors/chapter.sgml b/en/handbook/mirrors/chapter.sgml
index 0f4423b959..5f1a569539 100644
--- a/en/handbook/mirrors/chapter.sgml
+++ b/en/handbook/mirrors/chapter.sgml
@@ -1,1440 +1,1443 @@
Obtaining FreeBSDCD-ROM PublishersFreeBSD is available on CD-ROM from Walnut Creek CDROM:
Walnut Creek CDROM4041 Pike Lane, Suite FConcordCA, 94520USA
Phone: +1 925 674-0783
Fax: +1 925 674-0821
Email: info@cdrom.com
WWW: http://www.cdrom.com/FTP SitesThe official sources for FreeBSD are available via anonymous FTP
from:
ftp://ftp.FreeBSD.ORG/pub/FreeBSD.
The FreeBSD mirror
sites database is more accurate than the mirror listing in the
handbook, as it gets its information form the DNS rather than relying
on static lists of hosts.Additionally, FreeBSD is available via anonymous FTP from the
following mirror sites. If you choose to obtain FreeBSD via
anonymous FTP, please try to use a site near you.Argentina,
Australia,
Brazil,
Canada,
Czech Republic,
Denmark,
Estonia,
Spain,
Finland,
France,
Germany,
Hong Kong,
Ireland,
Israel,
Japan,
Korea,
Netherlands,
Poland,
Portugal,
Russia,
South Africa,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
Ukraine,
UK,
USA.ArgentinaIn case of problems, please contact the hostmaster hostmaster@ar.FreeBSD.ORG
for this domain.ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster hostmaster@au.FreeBSD.ORG
for this domain.ftp://ftp.au.FreeBSD.ORG/pub/FreeBSDftp://ftp2.au.FreeBSD.ORG/pub/FreeBSDftp://ftp3.au.FreeBSD.ORG/pub/FreeBSDftp://ftp4.au.FreeBSD.ORG/pub/FreeBSDBrazilIn case of problems, please contact the hostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDftp://ftp2.br.FreeBSD.ORG/pub/FreeBSDftp://ftp3.br.FreeBSD.ORG/pub/FreeBSDftp://ftp4.br.FreeBSD.ORG/pub/FreeBSDftp://ftp5.br.FreeBSD.ORG/pub/FreeBSDftp://ftp6.br.FreeBSD.ORG/pub/FreeBSDftp://ftp7.br.FreeBSD.ORG/pub/FreeBSDCanadaIn case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.ORG
for this domain.ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSDCzech Republicftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.DenmarkIn case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.ORG
for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.ORG
for this domain.ftp://ftp.ee.freebsd.ORG/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.ORG
for this domain.ftp://ftp.fi.freebsd.ORG/pub/FreeBSDFranceftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.GermanyIn case of problems, please contact the hostmaster hostmaster@de.FreeBSD.ORG
for this domain.ftp://ftp.de.FreeBSD.ORG/pub/FreeBSDftp://ftp2.de.FreeBSD.ORG/pub/FreeBSDftp://ftp3.de.FreeBSD.ORG/pub/FreeBSDftp://ftp4.de.FreeBSD.ORG/pub/FreeBSDftp://ftp5.de.FreeBSD.ORG/pub/FreeBSDftp://ftp6.de.FreeBSD.ORG/pub/FreeBSDftp://ftp7.de.FreeBSD.ORG/pub/FreeBSDHong Kongftp://ftp.hk.super.net/pub/FreeBSD Contact: ftp-admin@HK.Super.NET.IrelandIn case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.ORG
for this domain.ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster hostmaster@il.FreeBSD.ORG
for this domain.ftp://ftp.il.FreeBSD.ORG/pub/FreeBSDftp://ftp2.il.FreeBSD.ORG/pub/FreeBSDJapanIn case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.ORG
for this domain.ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSDKoreaIn case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.ORG
for this domain.ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp3.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp4.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp5.kr.FreeBSD.ORG/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.ORG
for this domain.ftp://ftp.nl.freebsd.ORG/pub/FreeBSDPolandIn case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.ORG
for this domain.ftp://ftp.pl.freebsd.ORG/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.ORG
for this domain.ftp://ftp.pt.freebsd.org/pub/FreeBSDftp://ftp2.pt.freebsd.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.ORG
for this domain.ftp://ftp.ru.freebsd.org/pub/FreeBSDftp://ftp2.ru.freebsd.org/pub/FreeBSDftp://ftp3.ru.freebsd.org/pub/FreeBSDftp://ftp4.ru.freebsd.org/pub/FreeBSDSouth AfricaIn case of problems, please contact the hostmaster hostmaster@za.FreeBSD.ORG
for this domain.ftp://ftp.za.FreeBSD.ORG/pub/FreeBSDftp://ftp2.za.FreeBSD.ORG/pub/FreeBSDftp://ftp3.za.FreeBSD.ORG/pub/FreeBSDSlovak RepublicIn case of problems, please contact the hostmaster
hostmaster@sk.FreeBSD.ORG for this domain.ftp://ftp.sk.freebsd.ORG/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster hostmaster@si.FreeBSD.ORG
for this domain.ftp://ftp.si.freebsd.ORG/pub/FreeBSDSpainIn case of problems, please contact the hostmaster
hostmaster@es.FreeBSD.ORG for this domain.ftp://ftp.es.freebsd.ORG/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster hostmaster@se.FreeBSD.ORG
for this domain.ftp://ftp.se.freebsd.ORG/pub/FreeBSDftp://ftp2.se.freebsd.ORG/pub/FreeBSDftp://ftp3.se.freebsd.ORG/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.ORG
for this domain.ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSDThailandftp://ftp.nectec.or.th/pub/FreeBSD Contact: ftpadmin@ftp.nectec.or.th.Ukraineftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: archer@lucky.net.
+ URL="ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD">ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: freebsd-mnt@lucky.net.
UKIn case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.ORG
for this domain.ftp://ftp.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp2.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp3.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp4.uk.FreeBSD.ORG/pub/FreeBSDUSAIn case of problems, please contact the hostmaster hostmaster@FreeBSD.ORG for
this domain.ftp://ftp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.FreeBSD.ORG/pub/FreeBSDftp://ftp3.FreeBSD.ORG/pub/FreeBSDftp://ftp4.FreeBSD.ORG/pub/FreeBSDftp://ftp5.FreeBSD.ORG/pub/FreeBSDftp://ftp6.FreeBSD.ORG/pub/FreeBSDThe latest versions of export-restricted code for FreeBSD (2.0C
or later) (eBones and secure) are being made available at the
following locations. If you are outside the U.S. or Canada, please
get secure (DES) and eBones (Kerberos) from one of the following
foreign distribution sites:South AfricaHostmaster hostmaster@internat.FreeBSD.ORG for this domain.ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSDftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSDBrazilHostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.CTM SitesCTM/FreeBSD is available via
anonymous FTP from the following mirror sites. If you choose to
obtain CTM via anonymous FTP, please try to use a site near
you.In case of problems, please contact &a.phk;.California, Bay Area, official sourceftp://ftp.freebsd.org/pub/FreeBSD/CTMGermany, Trierftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTMSouth Africa, backup server for old
deltasftp://ftp.internat.freebsd.org/pub/FreeBSD/CTMTaiwan/R.O.C, Chiayiftp://ctm.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm2.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm3.tw.freebsd.org/pub/freebsd/CTMIf you did not find a mirror near to you or the mirror is
incomplete, try FTP
search at http://ftpsearch.ntnu.no/ftpsearch. FTP search is a great free archie server in Trondheim, Norway.CVSup SitesCVSup servers for FreeBSD are
running at the following sites:Argentinacvsup.ar.FreeBSD.ORG (maintainer msagre@cactus.fi.uba.ar)Australiacvsup.au.FreeBSD.ORG (maintainer dawes@physics.usyd.edu.au)Brazilcvsup.br.FreeBSD.ORG (maintainer cvsup@cvsup.br.freebsd.org)Canadacvsup.ca.FreeBSD.ORG (maintainer james@ican.net)Denmarkcvsup.dk.FreeBSD.ORG (maintainer
jesper@skriver.dk)Estoniacvsup.ee.FreeBSD.ORG (maintainer taavi@uninet.ee)Finlandcvsup.fi.FreeBSD.ORG (maintainer count@key.sms.fi)Germanycvsup.de.FreeBSD.ORG (maintainer wosch@freebsd.org)cvsup2.de.FreeBSD.ORG (maintainer petzi@freebsd.org)cvsup3.de.FreeBSD.ORG (maintainer ag@leo.org)Icelandcvsup.is.FreeBSD.ORG (maintainer
adam@veda.is)Japancvsup.jp.FreeBSD.ORG (maintainer simokawa@sat.t.u-tokyo.ac.jp)cvsup2.jp.FreeBSD.ORG (maintainer max@FreeBSD.ORG)cvsup3.jp.FreeBSD.ORG (maintainer
shige@cin.nihon-u.ac.jp)cvsup4.jp.FreeBSD.ORG (maintainer
cvsup-admin@ftp.media.kyoto-u.ac.jp)cvsup5.jp.FreeBSD.ORG (maintainer
cvsup@imasy.or.jp)Netherlandscvsup.nl.FreeBSD.ORG (maintainer xaa@xaa.iae.nl)Norwaycvsup.no.FreeBSD.ORG (maintainer Tor.Egge@idt.ntnu.no)Polandcvsup.pl.FreeBSD.ORG (maintainer Mariusz@kam.pl)Russiacvsup.ru.FreeBSD.ORG (maintainer mishania@demos.su)Swedencvsup.se.FreeBSD.ORG (maintainer pantzer@ludd.luth.se)Slovak Republiccvsup.sk.FreeBSD.ORG (maintainer
tps@tps.sk)cvsup2.sk.FreeBSD.ORG (maintainer
tps@tps.sk)South Africacvsup.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)cvsup2.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)Taiwancvsup.tw.FreeBSD.ORG (maintainer jdli@freebsd.csie.nctu.edu.tw)Ukraine
- cvsup2.ua.FreeBSD.ORG (maintainer archer@lucky.net)
+ cvsup2.ua.FreeBSD.ORG (maintainer freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer joe@pavilion.net)USAcvsup.FreeBSD.ORG (maintainer skynyrd@opus.cts.cwu.edu)cvsup2.FreeBSD.ORG (maintainer jdp@FreeBSD.ORG)cvsup3.FreeBSD.ORG (maintainer wollman@FreeBSD.ORG)
+
+ cvsup4.FreeBSD.ORG (maintainer shmit@rcn.com)
+ The export-restricted code for FreeBSD (eBones and secure) is
available via CVSup at the following international repository.
Please use this site to get the export-restricted code, if you are
outside the USA or Canada.South Africacvsup.internat.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)The following CVSup site is especially designed for CTM users. Unlike the other CVSup mirrors,
it is kept up-to-date by CTM. That means if you CVSupcvs-all with release=cvs
from this site, you get a version of the repository (including the
inevitable .ctm_status file) which is
suitable for being updated using the CTMcvs-cur deltas. This allows users who track
the entire cvs-all tree to go from
CVSup to CTM without having to rebuild their repository from scratch
using a fresh CTM base delta.This special feature only works for the cvs-all distribution with
cvs as the release tag. CVSupping any other
distribution and/or release will get you the specified
distribution, but it will not be suitable for CTM updating.Because the current version of CTM does not preserve the
timestamps of files, the timestamps at this mirror site are not
the same as those at other mirror sites. Switching between this
site and other sites is not recommended. It will work correctly,
but will be somewhat inefficient.Germanyctm.FreeBSD.ORG (maintainer blank@fox.uni-trier.de)AFS SitesAFS servers for FreeBSD are running at the following sites;Swedenstacken.kth.se, Stacken
Computer Club, KTH, Sweden130.237.234.3, milko.stacken.kth.se130.237.234.43, hot.stacken.kth.se130.237.234.44, dog.stacken.kth.seMaintainer ftp@stacken.kth.se
diff --git a/en/handbook/pgpkeys/chapter.sgml b/en/handbook/pgpkeys/chapter.sgml
index cb1b9b9d1f..4323cc68e1 100644
--- a/en/handbook/pgpkeys/chapter.sgml
+++ b/en/handbook/pgpkeys/chapter.sgml
@@ -1,510 +1,579 @@
PGP keysIn case you need to verify a signature or send encrypted email to
one of the officers or core team members a number of keys are
provided here for your convenience.OfficersFreeBSD Security Officer security-officer@freebsd.org
FreeBSD Security Officer <security-officer@freebsd.org>
Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL
h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L
Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR
tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl
ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU
tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7
PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql
3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz
QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV
nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A
3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD
/REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb
5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS
9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B
sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P
BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT
0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx
ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD
ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO
v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1
lw==
=ipyA
-----END PGP PUBLIC KEY BLOCK-----&a.imp;
Warner Losh <imp@village.org>
aka <imp@freebsd.org>
Fingerprint = D4 31 FD B9 F7 90 17 E8 37 C5 E7 7F CF A6 C1 B9
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzDzTiAAAAEEAK8D7KWEbVFUrmlqhUEnAvphNIqHEbqqT8s+c5f5c2uHtlcH
V4mV2TlUaDSVBN4+/D70oHmZc4IgiQwMPCWRrSezg9z/MaKlWhaslc8YT6Xc1q+o
EP/fAdKUrq49H0QQbkQk6Ks5wKW6v9AOvdmsS6ZJEcet6d9G4dxynu/2qPVhAAUR
tCBNLiBXYXJuZXIgTG9zaCA8aW1wQHZpbGxhZ2Uub3JnPokAlQMFEDM/SK1VLh4u
c9KIpQEBFPsD/1n0YuuUPvD4CismZ9bx9M84y5sxLolgFEfP9Ux196ZSeaPpkA0g
C9YX/IyIy5VHh3372SDWN5iVSDYPwtCmZziwIV2YxzPtZw0nUu82P/Fn8ynlCSWB
5povLZmgrWijTJdnUWI0ApVBUTQoiW5MyrNN51H3HLWXGoXMgQFZXKWYiQCVAwUQ
MzmhkfUVW/uOVC1dAQG3+AP/T1HL/5EYF0ij0yQmNTzt1cLt0b1e3N3zN/wPFFWs
BfrQ+nsv1zw7cEgxLtktk73wBGM9jUIdJu8phgLtl5a0m9UjBq5oxrJaNJr6UTxN
a+sFkapTLT1g84UFUO/+8qRB12v+hZr2WeXMYjHAFUT18mp3xwjW9DUV+2fW1Wag
YDKJAJUDBRAzOYK1s1pi61mfMj0BARBbA/930CHswOF0HIr+4YYUs1ejDnZ2J3zn
icTZhl9uAfEQq++Xor1x476j67Z9fESxyHltUxCmwxsJ1uOJRwzjyEoMlyFrIN4C
dE0C8g8BF+sRTt7VLURLERvlBvFrVZueXSnXvmMoWFnqpSpt3EmN6TNaLe8Cm87a
k6EvQy0dpnkPKokAlQMFEDD9Lorccp7v9qj1YQEBrRUD/3N4cCMWjzsIFp2Vh9y+
RzUrblyF84tJyA7Rr1p+A7dxf7je3Zx5QMEXosWL1WGnS5vC9YH2WZwv6sCU61gU
rSy9z8KHlBEHh+Z6fdRMrjd9byPf+n3cktT0NhS23oXB1ZhNZcB2KKhVPlNctMqO
3gTYx+Nlo6xqjR+J2NnBYU8p =7fQV
-----END PGP PUBLIC KEY BLOCK-----Core Team members&a.asami;
Satoshi Asami <asami@cs.berkeley.edu>
aka <asami@FreeBSD.ORG>
Fingerprint = EB 3C 68 9E FB 6C EB 3F DB 2E 0F 10 8F CE 79 CA
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzPVyoQAAAEEAL7W+kipxB171Z4SVyyL9skaA7hG3eRsSOWk7lfvfUBLtPog
f3OKwrApoc/jwLf4+Qpdzv5DLEt/6Hd/clskhJ+q1gMNHyZ5ABmUxrTRRNvJMTrb
3fPU3oZj7sL/MyiFaT1zF8EaMP/iS2ZtcFsbYOqGeA8E/58uk4NA0SoeCNiJAAUR
tCVTYXRvc2hpIEFzYW1pIDxhc2FtaUBjcy5iZXJrZWxleS5lZHU+iQCVAwUQM/AT
+EqGN2HYnOMZAQF11QP/eSXb2FuTb1yX5yoo1Im8YnIk1SEgCGbyEbOMMBznVNDy
5g2TAD0ofLxPxy5Vodjg8rf+lfMVtO5amUH6aNcORXRncE83T10JmeM6JEp0T6jw
zOHKz8jRzygYLBayGsNIJ4BGxa4LeaGxJpO1ZEvRlNkPH/YEXK5oQmq9/DlrtYOJ
AEUDBRAz42JT8ng6GBbVvu0BAU8nAYCsJ8PiJpRUGlrz6rxjX8hqM1v3vqFHLcG+
G52nVMBSy+RZBgzsYIPwI5EZtWAKb22JAJUDBRAz4QBWdbtuOHaj97EBAaQPA/46
+NLUp+Wubl90JoonoXocwAg88tvAUVSzsxPXj0lvypAiSI2AJKsmn+5PuQ+/IoQy
lywRsxiQ5GD7C72SZ1yw2WI9DWFeAi+qa4b8n9fcLYrnHpyCY+zxEpu4pam8FJ7H
JocEUZz5HRoKKOLHErzXDiuTkkm72b1glmCqAQvnB4kAlQMFEDPZ3gyDQNEqHgjY
iQEBFfUEALu2C0uo+1Z7C5+xshWRYY5xNCzK20O6bANVJ+CO2fih96KhwsMof3lw
fDso5HJSwgFd8WT/sR+Wwzz6BAE5UtgsQq5GcsdYQuGI1yIlCYUpDp5sgswNm+OA
bX5a+r4F/ZJqrqT1J56Mer0VVsNfe5nIRsjd/rnFAFVfjcQtaQmjiQCVAwUQM9uV
mcdm8Q+/vPRJAQELHgP9GqNiMpLQlZig17fDnCJ73P0e5t/hRLFehZDlmEI2TK7j
Yeqbw078nZgyyuljZ7YsbstRIsWVCxobX5eH1kX+hIxuUqCAkCsWUY4abG89kHJr
XGQn6X1CX7xbZ+b6b9jLK+bJKFcLSfyqR3M2eCyscSiZYkWKQ5l3FYvbUzkeb6K0
IVNhdG9zaGkgQXNhbWkgPGFzYW1pQEZyZWVCU0QuT1JHPg==
=39SC
-----END PGP PUBLIC KEY BLOCK-----&a.jmb;
Jonathan M. Bresler <jmb@FreeBSD.org>
f16 Fingerprint16 = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNbtI
gAHbXdKX5jjdAQHamQP+OQr10QRknamIPmuHmFYJZ0jU9XPIvTTMuOiUYLcXlTdn
GyTUuzhbEywgtOldW2V5iA8platXThtqC68NsnN/xQfHA5xmFXVbayNKn8H5stDY
2s/4+CZ06mmJfqYmONF1RCbUk/M84rVT3Gn2tydsxFh4Pm32lf4WREZWRiLqmw+J
AJUDBRA0DfF99RVb+45ULV0BAcZ0BACCydiSUG1VR0a5DBcHdtin2iZMPsJUPRqJ
tWvP6VeI8OFpNWQ4LW6ETAvn35HxV2kCcQMyht1kMD+KEJz7r8Vb94TS7KtZnNvk
2D1XUx8Locj6xel5c/Lnzlnnp7Bp1XbJj2u/NzCaZQ0eYBdP/k7RLYBYHQQln5x7
BOuiRJNVU4kAlQMFEDQLcShVLh4uc9KIpQEBJv4D/3mDrD0MM9EYOVuyXik3UGVI
8quYNA9ErVcLdt10NjYc16VI2HOnYVgPRag3Wt7W8wlXShpokfC/vCNt7f5JgRf8
h2a1/MjQxtlD+4/Js8k7GLa53oLon6YQYk32IEKexoLPwIRO4L2BHWa3GzHJJSP2
aTR/Ep90/pLdAOu/oJDUiQCVAwUQMqyL0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz
2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyWCGw49XR/vPKYIJY9EYo4t49GIajRkISQ
NNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4dybo7oEKYMWWijQzGjqf2m8wf9OaaofE
KwBX6nxcRbKsxm/BVLKczGYl3XtjkcuJAJUDBRA1ol5TZWCprDT5+dUBATzXA/9h
/ZUuhoRKTWViaistGJfWi26FB/Km5nDQBr/Erw3XksQCMwTLyEugg6dahQ1u9Y5E
5tKPxbB69eF+7JXVHE/z3zizR6VL3sdRx74TPacPsdhZRjChEQc0htLLYAPkJrFP
VAzAlSlm7qd+MXf8fJovQs6xPtZJXukQukPNlhqZ94kAPwMFEDSH/kF4tXKgazlt
bxECfk4AoO+VaFVfguUkWX10pPSSfvPyPKqiAJ4xn8RSIe1ttmnqkkDMhLh00mKj
lLQuSm9uYXRoYW4gTS4gQnJlc2xlciA8Sm9uYXRoYW4uQnJlc2xlckBVU2kubmV0
PokAlQMFEDXbdSkB213Sl+Y43QEBV/4D/RLJNTrtAqJ1ATxXWv9g8Cr3/YF0GTmx
5dIrJOpBup7eSSmiM/BL9Is4YMsoVbXCI/8TqA67TMICvq35PZU4wboQB8DqBAr+
gQ8578M7Ekw1OAF6JXY6AF2P8k7hMcVBcVOACELPT/NyPNByG5QRDoNmlsokJaWU
/2ls4QSBZZlb
=zbCw
-----END PGP PUBLIC KEY BLOCK-----&a.ache;
Andrey A. Chernov <ache@FreeBSD.org>
aka <ache@nagual.pp.ru>
Key fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs
Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD
m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT
tCVBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucHAucnU+iQCVAwUQM2Ez
u+JgpPLZnQjrAQEyugP8DPnS8ixJ5OeuYgPFQf5sy6l+LrB6hyaS+lgsUPahWjNY
cnaDmfda/q/BV5d4+y5rlQe/pjnYG7/yQuAR3jhlXz8XDrqlBOnW9AtYjDt5rMfJ
aGFTGXAPGZ6k6zQZE0/YurT8ia3qjvuZm3Fw4NJrHRx7ETHRvVJDvxA6Ggsvmr20
JEFuZHJleSBBLiBDaGVybm92IDxhY2hlQEZyZWVCU0Qub3JnPokAlQMFEDR5uVbi
YKTy2Z0I6wEBLgED/2mn+hw4/3peLx0Sb9LNx//NfCCkVefSf2G9Qwhx6dvwbX7h
mFca97h7BQN4GubU1Z5Ffs6TeamSBrotBYGmOCwvJ6S9WigF9YHQIQ3B4LEjskAt
pcjU583y42zM11kkvEuQU2Gde61daIylJyOxsgpjSWpkxq50fgY2kLMfgl/ftCZB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuaWV0enNjaGUubmV0PokAlQMFEDR5svDi
YKTy2Z0I6wEBOTQD/0OTCAXIjuak363mjERvzSkVsNtIH9hA1l0w6Z95+iH0fHrW
xXKT0vBZE0y0Em+S3cotLL0bMmVE3F3D3GyxhBVmgzjyx0NYNoiQjYdi+6g/PV30
Cn4vOO6hBBpSyI6vY6qGNqcsawuRtHNvK/53MpOfKwSlICEBYQimcZhkci+EtCJB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJgpPLZ
nQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqKK8QY
rr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK/k7B
gI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFuZHJl
eSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+iQCV
AwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj4GPa
o3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI5apJ
mWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/osnzC
Cw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOvaoGr
anxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPriu8dI
rlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD7Hv8
vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZYMFO
DHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VSTGlh
Bhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+Mtun9
KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/YC3a
hs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1tGR3b
vz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwOTNQI
AOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fteFRkB
AWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96xnaa5
MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYiI0UA
Iwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAOz6qx
/IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBpYsfA
+6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzutZiM
1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cdiQCV
AwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgRsWFM
y9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8JkRv
Cn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6bLMV
HEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT1b14
5po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvlOm3R
rsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQPTi3
5SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qOx9Fw
erGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVjDHH5
+uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgbyldq6
EB33OunazFcfZFRIcXk1sfyLDvYE
=1ahV
-----END PGP PUBLIC KEY BLOCK-----&a.jkh;
Jordan K. Hubbard <jkh@FreeBSD.org>
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokBFQMFEDXCTXQM
j46yp4IfPQEBwO8IAIN0J09AXBf86dFUTFGcAMrEQqOF5IL+KGorAjzuYxERhKfD
ZV7jA+sCQqxkWfcVcE20kVyVYqzZIkio9a5zXP6TwA247JkPt54S1PmMDYHNlRIY
laXlNoji+4q3HP2DfHqXRT2859rYpm/fG/v6pWkos5voPKcZ2OFEp9W+Ap88oqw+
5rx4VetZNJq1Epmis4INj6XqNqj85+MOOIYE+f445ohDM6B/Mxazd6cHFGGIR+az
VjZ6lCDMLjzhB5+FqfrDLYuMjqkMTR5z9DL+psUvPlCkYbQ11NEWtEmiIWjUcNJN
GCxGzv5bXk0XPu3ADwbPkFE2usW1cSM7AQFiwuyJAJUDBRAxe+Q9a1pnjYGyp3kB
AV7XA/oCSL/Cc2USpQ2ckwkGpyvIkYBPszIcabSNJAzm2hsU9Qa6WOPxD8olDddB
uJNiW/gznPC4NsQ0N8Zr4IqRX/TTDVf04WhLmd8AN9SOrVv2q0BKgU6fLuk979tJ
utrewH6PR2qBOjAaR0FJNk4pcYAHeT+e7KaKy96YFvWKIyDvc4kAlQMFEDF8ldof
f6kIA1j8vQEBDH4D/0Zm0oNlpXrAE1EOFrmp43HURHbij8n0Gra1w9sbfo4PV+/H
U8ojTdWLy6r0+prH7NODCkgtIQNpqLuqM8PF2pPtUJj9HwTmSqfaT/LMztfPA6PQ
csyT7xxdXl0+4xTDl1avGSJfYsI8XCAy85cTs+PQwuyzugE/iykJO1Bnj/paiQCV
AwUQMXvlBvUVW/uOVC1dAQF2fQP/RfYC6RrpFTZHjo2qsUHSRk0vmsYfwG5NHP5y
oQBMsaQJeSckN4n2JOgR4T75U4vS62aFxgPLJP3lOHkU2Vc7xhAuBvsbGr5RP8c5
LvPOeUEyz6ZArp1KUHrtcM2iK1FBOmY4dOYphWyWMkDgYExabqlrAq7FKZftpq/C
BiMRuaw=
=C/Jw
-----END PGP PUBLIC KEY BLOCK-----&a.phk;
Poul-Henning Kamp <phk@FreeBSD.org>
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDQQ0aZ1
u244dqP3sQEBu4ID/jXFFeJgs2MdTDNOZM/FbfDhI4qxAbYUsqS3+Ra16yd8Wd/A
jV+IHJE2NomFWl8UrUjCGinXiwzPgK1OfFJrS9Og1wQLvAl0X84BA8MTP9BQr4w7
6I/RbksgUSrVCIO8MJwlydjSPocWGBeXlVjbZxXzyuJk7H+TG+zuI5BuBcNIiQCV
AwUQMwYr2rNaYutZnzI9AQHiIQP/XxtBWFXaBRgVLEhRNpS07YdU+LsZGlLOZehN
9L4UnJFHQQPNOpMey2gF7Y95aBOw5/1xS5vlQpwmRFCntWsm/gqdzK6rulfr1r5A
y94LO5TAC6ucNu396Y4vo1TyD1STnRC466KlvmtQtAtFGgXlORWLL9URLzcRFd1h
D0yXd9aJAJUDBRAxfo19a1pnjYGyp3kBAQqyA/4v64vP3l1F0Sadn6ias761hkz/
SMdTuLzILmofSCC4o4KWMjiWJHs2Soo41QlZi1+xMHzV32JKiwFlGtPHqL+EHyXy
Q4H3vmf9/1KF+0XCaMtgI0wWUMziPSTJK8xXbRRmMDK/0F4TnVVaUhnmf+h5K7O6
XdmejDTa0X/NWcicmIkAlQMFEDF8lef1FVv7jlQtXQEBcnwD/0ro1PpUtlkLmreD
tsGTkNa7MFLegrYRvDDrHOwPZH152W2jPUncY+eArQJakeHiTDmJNpFagLZglhE0
bqJyca+UwCXX+6upAclWHEBMg2byiWMMqyPVEEnpUoHM1sIkgdNWlfQAmipRBfYh
2LyCgWvR8CbtwPYIFvUmGgB3MR87iQCVAwUQMUseXB9/qQgDWPy9AQGPkwP/WEDy
El2Gkvua9COtMAifot2vTwuvWWpNopIEx0Ivey4aVbRLD90gGCJw8OGDEtqFPcNV
8aIiy3fYVKXGZZjvCKd7zRfhNmQn0eLDcymq2OX3aPrMc2rRlkT4Jx425ukR1gsO
qiQAgw91aWhY8dlw/EKzk8ojm52x4VgXaBACMjaJAJUDBRAxOUOg72G56RHVjtUB
AbL4A/9HOn5Qa0lq9tKI/HkSdc5fGQD/66VdCBAb292RbB7CS/EM07MdbcqRRYIa
0+0gwQ3OdsWPdCVgH5RIhp/WiC+UPkR1cY8N9Mg2kTwJfZZfNqN+BgWlgRMPN27C
OhYNl8Q33Nl9CpBLrZWABF44jPeT0EvvTzP/5ZQ7T75EsYKYiYkAlQMFEDDmryQA
8tkJ67sbQQEBPdsEALCj6v1OBuJLLJTlxmmrkqAZPVzt5QdeO3Eqa2tcPWcU0nqP
vHYMzZcZ7oFg58NZsWrhSQQDIB5e+K65Q/h6dC7W/aDskZd64jxtEznX2kt0/MOr
8OdsDis1K2f9KQftrAx81KmVwW4Tqtzl7NWTDXt44fMOtibCwVq8v2DFkTJy
=JKbP
-----END PGP PUBLIC KEY BLOCK-----&a.rich;
Rich Murphey <rich@FreeBSD.org>
fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1
FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs
wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR
tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W
vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g
Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP
/2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw==
=QoiM
-----END PGP PUBLIC KEY BLOCK-----&a.jdp;
John D. Polstra <jdp@polstra.com>
Fingerprint = 54 3A 90 59 6B A4 9D 61 BF 1D 03 09 35 8D F6 0D
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzMElMEAAAEEALizp6ZW9QifQgWoFmG3cXhzQ1+Gt+a4S1adC/TdHdBvw1M/
I6Ok7TC0dKF8blW3VRgeHo4F3XhGn+n9MqIdboh4HJC5Iiy63m98sVLJSwyGO4oM
dkEGyyCLxqP6h/DU/tzNBdqFzetGtYvU4ftt3RO0a506cr2CHcdm8Q+/vPRJAAUR
tCFKb2huIEQuIFBvbHN0cmEgPGpkcEBwb2xzdHJhLmNvbT6JAJUDBRAzBNBE9RVb
+45ULV0BAWgiA/0WWO3+c3qlptPCHJ3DFm6gG/qNKsY94agL/mHOr0fxMP5l2qKX
O6a1bWkvGoYq0EwoKGFfn0QeHiCl6jVi3CdBX+W7bObMcoi+foqZ6zluOWBC1Jdk
WQ5/DeqQGYXqbYjqO8voCScTAPge3XlMwVpMZTv24u+nYxtLkE0ZcwtY9IkAlQMF
EDMEt/DHZvEPv7z0SQEBXh8D/2egM5ckIRpGz9kcFTDClgdWWtlgwC1iI2p9gEhq
aufy+FUJlZS4GSQLWB0BlrTmDC9HuyQ+KZqKFRbVZLyzkH7WFs4zDmwQryLV5wkN
C4BRRBXZfWy8s4+zT2WQD1aPO+ZsgRauYLkJgTvXTPU2JCN62Nsd8R7bJS5tuHEm
7HGmiQCVAwUQMwSvHB9/qQgDWPy9AQFAhAQAgJ1AlbKITrEoJ0+pLIsov3eQ348m
SVHEBGIkU3Xznjr8NzT9aYtq4TIzt8jplqP3QoV1ka1yYpZf0NjvfZ+ffYp/sIaU
wPbEpgtmHnVWJAebMbNs/Ad1w8GDvxEt9IaCbMJGZnHmfnEqOBIxF7VBDPHHoJxM
V31K/PIoYsHAy5w=
=cHFa
-----END PGP PUBLIC KEY BLOCK-----&a.guido;
Guido van Rooij <guido@gvr.win.tue.nl>
Fingerprint = 16 79 09 F3 C0 E4 28 A7 32 62 FA F6 60 31 C0 ED
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzGeO84AAAEEAKKAY91Na//DXwlUusr9GVESSlVwVP6DyH1wcZXhfN1fyZHq
SwhMCEdHYoojQds+VqD1iiZQvv1RLByBgj622PDAPN4+Z49HjGs7YbZsUNuQqPPU
wRPpP6ty69x1hPKq1sQIB5MS4radpCM+4wbZbhxv7l4rP3RWUbNaYutZnzI9AAUR
tCZHdWlkbyB2YW4gUm9vaWogPGd1aWRvQGd2ci53aW4udHVlLm5sPokAlQMFEDMG
Hcgff6kIA1j8vQEBbYgD/jm9xHuUuY+iXDkOzpCXBYACYEZDV913MjtyBAmaVqYo
Rh5HFimkGXe+rCo78Aau0hc57fFMTsJqnuWEqVt3GRq28hSK1FOZ7ni9/XibHcmN
rt2yugl3hYpClijo4nrDL1NxibbamkGW/vFGcljS0jqXz6NDVbGx5Oo7HBByxByz
iQCVAwUQMhmtVjt/x7zOdmsfAQFuVQQApsVUTigT5YWjQA9Nd5Z0+a/oVtZpyw5Z
OljLJP3vqJdMa6TidhfcatjHbFTve5x1dmjFgMX/MQTd8zf/+Xccy/PX4+lnKNpP
eSf1Y4aK+E8KHmBGd6GzX6CIboyGYLS9e3kGnN06F2AQtaLyJFgQ71wRaGuyKmQG
FwTn7jiKb1aJAJUDBRAyEOLXPt3iN6QQUSEBATwQA/9jqu0Nbk154+Pn+9mJX/YT
fYR2UqK/5FKCqgL5Nt/Deg2re0zMD1f8F9Dj6vuAAxq8hnOkIHKlWolMjkRKkzJi
mSPEWl3AuHJ31k948J8it4f8kq/o44usIA2KKVMlI63Q/rmNdfWCyiYQEVGcRbTm
GTdZIHYCOgV5dOo4ebFqgYkAlQMFEDIE1nMEJn15jgpJ0QEBW6kEAKqN8XSgzTqf
CrxFXT07MlHhfdbKUTNUoboxCGCLNW05vf1A8F5fdE5i14LiwkldWIzPxWD+Sa3L
fNPCfCZTaCiyGcLyTzVfBHA18MBAOOX6JiTpdcm22jLGUWBf/aJK3yz/nfbWntd/
LRHysIdVp29lP5BF+J9/Lzbb/9LxP1taiQCVAwUQMgRXZ44CzbsJWQz9AQFf7gP/
Qa2FS5S6RYKG3rYanWADVe/ikFV2lxuM1azlWbsmljXvKVWGe6cV693nS5lGGAjx
lbd2ADwXjlkNhv45HLWFm9PEveO9Jjr6tMuXVt8N2pxiX+1PLUN9CtphTIU7Yfjn
s6ryZZfwGHSfIxNGi5ua2SoXhg0svaYnxHxXmOtH24iJAJUDBRAyAkpV8qaAEa3W
TBkBARfQBAC+S3kbulEAN3SI7/A+A/dtl9DfZezT9C4SRBGsl2clQFMGIXmMQ/7v
7lLXrKQ7U2zVbgNfU8smw5h2vBIL6f1PyexSmc3mz9JY4er8KeZpcf6H0rSkHl+i
d7TF0GvuTdNPFO8hc9En+GG6QHOqbkB4NRZ6cwtfwUMhk2FHXBnjF4kAlQMFEDH5
FFukUJAsCdPmTQEBe74EAMBsxDnbD9cuI5MfF/QeTNEG4BIVUZtAkDme4Eg7zvsP
d3DeJKCGeNjiCWYrRTCGwaCWzMQk+/+MOmdkI6Oml+AIurJLoHceHS9jP1izdP7f
N2jkdeJSBsixunbQWtUElSgOQQ4iF5kqwBhxtOfEP/L9QsoydRMR1yB6WPD75H7V
iQCVAwUQMZ9YNGtaZ42Bsqd5AQH0PAQAhpVlAc3ZM/KOTywBSh8zWKVlSk3q/zGn
k7hJmFThnlhH1723+WmXE8aAPJi+VXOWJUFQgwELJ6R8jSU2qvk2m1VWyYSqRKvc
VRQMqT2wjss0GE1Ngg7tMrkRHT0il7E2xxIb8vMrIwmdkbTfYqBUhhGnsWPHZHq7
MoA1/b+rK7CJAJUDBRAxnvXh3IDyptUyfLkBAYTDA/4mEKlIP/EUX2Zmxgrd/JQB
hqcQlkTrBAaDOnOqe/4oewMKR7yaMpztYhJs97i03Vu3fgoLhDspE55ooEeHj0r4
cOdiWfYDsjSFUYSPNVhW4OSruMA3c29ynMqNHD7hpr3rcCPUi7J2RncocOcCjjK2
BQb/9IAUNeK4C9gPxMEZLokAlQMFEDGeO86zWmLrWZ8yPQEBEEID/2fPEUrSX3Yk
j5TJPFZ9MNX0lEo7AHYjnJgEbNI4pYm6C3PnMlsYfCSQDHuXmRQHAOWSdwOLvCkN
F8eDaF3M6u0urgeVJ+KVUnTz2+LZoZs12XSZKCte0HxjbvPpWMTTrYyimGezH79C
mgDVjsHaYOx3EXF0nnDmtXurGioEmW1J
=mSvM
-----END PGP PUBLIC KEY BLOCK-----&a.peter;
Peter Wemm <peter@FreeBSD.org>
aka <peter@spinner.dialix.com>
aka <peter@haywire.dialix.com>
aka <peter@perth.dialix.oz.au>
Key fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/
W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2
kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT
tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMwWT
cXW7bjh2o/exAQEFkQP+LIx5zKlYp1uR24xGApMFNrNtjh+iDIWnxxb2M2Kb6x4G
9z6OmbUCoDTGrX9SSL2Usm2RD0BZfyv9D9QRWC2TSOPkPRqQgIycc11vgbLolJJN
eixqsxlFeKLGEx9eRQCCbo3dQIUjc2yaOe484QamhsK1nL5xpoNWI1P9zIOpDiGJ
AJUDBRAxsRPqSoY3Ydic4xkBAbWLA/9q1Fdnnk4unpGQsG31Qbtr4AzaQD5m/JHI
4gRmSmbj6luJMgNG3fpO06Gd/Z7uxyCJB8pTst2a8C/ljOYZxWT+5uSzkQXeMi5c
YcI1sZbUpkHtmqPW623hr1PB3ZLA1TIcTbQW+NzJsxQ1Pc6XG9fGkT9WXQW3Xhet
AP+juVTAhLQlUGV0ZXIgV2VtbSA8cGV0ZXJAcGVydGguZGlhbGl4Lm96LmF1PokA
lQMFEDGxFCFKhjdh2JzjGQEB6XkD/2HOwfuFrnQUtdwFPUkgtEqNeSr64jQ3Maz8
xgEtbaw/ym1PbhbCk311UWQq4+izZE2xktHTFClJfaMnxVIfboPyuiSF99KHiWnf
/Gspet0S7m/+RXIwZi1qSqvAanxMiA7kKgFSCmchzas8TQcyyXHtn/gl9v0khJkb
/fv3R20btB5QZXRlciBXZW1tIDxwZXRlckBGcmVlQlNELm9yZz6JAJUDBRAxsRJd
SoY3Ydic4xkBAZJUA/4i/NWHz5LIH/R4IF/3V3LleFyMFr5EPFY0/4mcv2v+ju9g
brOEM/xd4LlPrx1XqPeZ74JQ6K9mHR64RhKR7ZJJ9A+12yr5dVqihe911KyLKab9
4qZUHYi36WQu2VtLGnw/t8Jg44fQSzbBF5q9iTzcfNOYhRkSD3BdDrC3llywO7Ql
UGV0ZXIgV2VtbSA8cGV0ZXJAc3Bpbm5lci5kaWFsaXguY29tPokAlQMFEDGxEi1K
hjdh2JzjGQEBdA4EAKmNFlj8RF9HQsoI3UabnvYqAWN5wCwEB4u+Zf8zq6OHic23
TzoK1SPlmSdBE1dXXQGS6aiDkLT+xOdeewNs7nfUIcH/DBjSuklAOJzKliXPQW7E
kuKNwy4eq5bl+j3HB27i+WBXhn6OaNNQY674LGaR41EGq44Wo5ATcIicig/z
=gv+h
-----END PGP PUBLIC KEY BLOCK-----&a.joerg;
Type Bits/KeyID Date User ID
pub 1024/76A3F7B1 1996/04/27 Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Key fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
Joerg Wunsch <joerg_wunsch@interface-business.de>
Joerg Wunsch <j@uriah.heep.sax.de>
Joerg Wunsch <j@interface-business.de>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz
q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe
ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR
tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J
AJUDBRA0FFkBs1pi61mfMj0BAfDCA/oCfkjrhvRwRCpSL8klJ1YDoUJdmw+v4nJc
pw3OpYXbwKOPLClsE7K3KCQscHel7auf91nrekAwbrXv9Clp0TegYeAQNjw5vZ9f
L6UZ5l3fH8E2GGA7+kqgNWs1KxAnG5GdUvJ9viyrWm8dqWRGo+loDWlZ12L2OgAD
fp7jVZTI1okAlQMFEDQPrLoff6kIA1j8vQEB2XQEAK/+SsQPCT/X4RB/PBbxUr28
GpGJMn3AafAaA3plYw3nb4ONbqEw9tJtofAn4UeGraiWw8nHYR2DAzoAjR6OzuX3
TtUV+57BIzrTPHcNkb6h8fPuHU+dFzR+LNoPaGJsFeov6w+Ug6qS9wa5FGDAgaRo
LHSyBxcRVoCbOEaS5S5EiQCVAwUQM5BktWVgqaw0+fnVAQGKPwP+OiWho3Zm2GKp
lEjiZ5zx3y8upzb+r1Qutb08jr2Ewja04hLg0fCrt6Ad3DoVqxe4POghIpmHM4O4
tcW92THQil70CLzfCxtfUc6eDzoP3krD1/Gwpm2hGrmYA9b/ez9+r2vKBbnUhPmC
glx5pf1IzHU9R2XyQz9Xu7FI2baOSZqJAJUDBRAyCIWZdbtuOHaj97EBAVMzA/41
VIph36l+yO9WGKkEB+NYbYOz2W/kyi74kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoL
oAKxE25AoCgl5towqr/sCcu0A0MMvJddUvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zz
xzLIvtcio6kaHd76XxyJpltCASupdD53nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxq
b2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDIIhfR1u244
dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX
+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvckfxvrTgzSzvtYyv1072X3GkVY+SlUMBMA
rdl1qNW23oT7Q558ajnsaL065XJ5m7HacgTTikiofYG8i1s7TrsEeq6PtCJKb2Vy
ZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5zYXguZGU+iQCVAwUQMaS91D4gHQUlG9CZ
AQGYOwQAhPpiobK3d/fz+jWrbQgjkoO+j39glYGXb22+6iuEprFRs/ufKYtjljNT
NK3B4DWSkyIPawcuO4Lotijp6jke2bsjFSSashGWcsJlpnwsv7EeFItT3oWTTTQQ
ItPbtNyLW6M6xB+jLGtaAvJqfOlzgO9BLfHuA2LY+WvbVW447SWJAJUDBRAxqWRs
dbtuOHaj97EBAXDBA/49rzZB5akkTSbt/gNd38OJgC+H8N5da25vV9dD3KoAvXfW
fw7OxIsxvQ/Ab+rJmukrrWxPdsC+1WU1+1rGa4PvJp/VJRDes2awGrn+iO7/cQoS
IVziC27JpcbvjLvLVcBIiy1yT/RvJ+87a3jPRHt3VFGcpFh4KykxxSNiyGygl4kA
lQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJZe5lFkPr2B/Cr7BKMVBot1/JSu05NsHg
JZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDFe/GF0HZD/ZD1FJt8yQjzF2w340B+F2GG
EOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gpkFZrFgg5eON7ikqmusDnOlYStM/CBfgp
SbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokA
lQMFEDHioSdlYKmsNPn51QEByz8D/10uMrwP7MdaXnptd1XNFhpaAPYTVAOcaKlY
OGI/LLR9PiU3FbqXO+7INhaxFjBxa0Tw/p4au5Lq1+Mx81edHniJZNS8tz3I3goi
jIC3+jn2gnVAWnK5UZUTUVUn/JLVk/oSaIJNIMMDaw4J9xPVVkb+Fh1A+XqtPsVa
YESrNp0+iQCVAwUQMwXkzcdm8Q+/vPRJAQEA4QQAgNNX1HFgXrMetDb+w6yEGQDk
JCDAY9b6mA2HNeKLQAhsoZl4HwA1+iuQaCgo3lyFC+1Sf097OUTs74z5X1vCedqV
oFw9CxI3xuctt3pJCbbN68flOlnq0WdYouWWGlFwLlh5PEy//VtwX9lqgsizlhzi
t+fX6BT4BgKi5baDhrWJAJUDBRAyCKveD9eCJxX4hUkBAebMA/9mRPy6K6i7TX2R
jUKSl2p5oYrXPk12Zsw4ijuktslxzQhOCyMSCGK2UEC4UM9MXp1H1JZQxN/DcfnM
7VaUt+Ve0wZ6DC9gBSHJ1hKVxHe5XTj26mIr4rcXNy2XEDMK9QsnBxIAZnBVTjSO
LdhqqSMp3ULLOpBlRL2RYrqi27IXr4kAlQMFEDGpbnd1u244dqP3sQEBJnQD/RVS
Azgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyudZkNkI5zGGDwVneH/cSkKT4OR
ooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8orsQGGWIn5FhqYXsKkjEGxIOBOf
vvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU
=97h7
-----END PGP PUBLIC KEY BLOCK-----
+
+
+ Developers
+
+
+ &a.wosch;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/2B7181AD 1997/08/09 Wolfram Schneider <wosch@FreeBSD.org>
+Fingerprint = CA 16 91 D9 75 33 F1 07 1B F0 B4 9F 3E 95 B6 09
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzPs+aEAAAEEAJqqMm2I9CxWMuHDvuVO/uh0QT0az5ByOktwYLxGXQmqPG1G
+Q3hVuHWYs5Vfm/ARU9CRcVHFyqGQ3LepoRhDHk+JcASHan7ptdFsz7xk1iNNEoe0
+vE2rns38HIbiyQ/2OZd4XsyhFOFtExNoBuyDyNoe3HbHVBQT7TmN/mkrcYGtAAUR
+tCVXb2xmcmFtIFNjaG5laWRlciA8d29zY2hARnJlZUJTRC5vcmc+iQCVAwUQNmrS
+AzmN/mkrcYGtAQFQjAP8CthNueur8XDAZqC5q6NQcDs0PqqQ+raTUfQTv6Km6ykf
+UzdpDlBoRC+CCyHfBfC5zo9N6mB7iV7qS1PljrdIh6VAwHxJN9iopB/x6+nsBvmy
+0YSNt7eyfFrIVegCJvd4ALz5JBV8ZstznOwo8RAhDD0gX58F8nDhgWjy62JekGK0
+IldvbGZyYW0gU2NobmVpZGVyIDx3b3NjaEBhcGZlbC5kZT6JARUDBRA2Z9ZcCMks
+sk6wLt0BAQBICACcTiDZ/AyYWRDLXsBOK+WMRoNk3+bQZ1cdy11nwJo+taT/389M
+0r5TrEJ7CogpXC2rFUExTVWldSFZd8A1YIHtrTsP7YauUH0nA7k0wUnqDRYj8YJR
+eMLFvc1OQ2y+mkvxF2BzzBzh/bcYbgJdWCB1MPahSNQfkGXtp+A5PjEs8Cp4+FLu
+EUFScyxsD3g5/E+0d7mirJpe3pxcf9KCmFGHM89mrTKODQR/7N8dVqa9npeXZotm
+ZK8Jz+tvRKFgNiLf2XL048+IE8ZtJXDYaDzTirHdcAqJMWQuxthCdG3ta4I+w5WM
+WR8JtBLfVNpyU7LN6dl0IB7O5sYhyskApmMwiQCVAwUQM+z5oTmN/mkrcYGtAQGU
+gAP/cJGro/SbV+L19s/Gem26KmegUH+bfIXoh2EzyRJ7heVdybu1LrSDFApmAE7d
+sMDlAA1wd2XjVWD3nIEBl6k+J7qJB4ACjKVGs414jLpdKGPHdLRYqYDj4LyQFMv6
+/BpSoX1gnWp6xlC2xeWRan9ns3XZGS55UBVDvBE/B+fPoTe0JFdvbGZyYW0gU2No
+bmVpZGVyIDxzY2huZWlkZXJAemliLmRlPokAlQMFEDZq0dI5jf5pK3GBrQEB38QD
+/3NYyRPIejtXXq/okdDRyhWmA8cv0KG6gEupKCQKa7ep/OZTw/KxrN3ZOS8zlPod
+tEn8mol+4SvY5AgSMdjQ0jTd1JdFcMKFnbJJrJ3b9IpwCqbkXy25rTUcQn9ICP47
+rFKC4qR/Ucrg5YVVhQ3pVJX6XuO2XvuG7euHAQNXV3e2
+=EpJQ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+ &a.brian;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/666A7421 1997/04/30 Brian Somers <brian@Awfulhak.org>
+ Key fingerprint = 2D 91 BD C2 94 2C 46 8F 8F 09 C4 FC AD 12 3B 21
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzNmogUAAAEEALdsjVsV2dzO8UU4EEo7z3nYuvB2Q6YJ8sBUYjB8/vfR5oZ9
+7aEQjgY5//pXvS30rHUB9ghk4kIFSljzeMudE0K2zH5n2sxpLbBKWZRDLS7xnrDC
+I3j9CNKwQBzMPs0fUT46gp96nf1X8wPiJXkDUEia/c0bRbXlLw7tvOdmanQhAAUR
+tCFCcmlhbiBTb21lcnMgPGJyaWFuQGF3ZnVsaGFrLm9yZz6JAJUDBRAzbedc77Ox
+BWZTbW0BAVtFA/42QelA3RBXYUtIcYGob+QsWkA1kGyBKQGPSS9coHdUVjClBRl3
+UZFmZhxAODb7cBRXmpvx2ZuMrhn/MpXTMqPOJaE3FYm+5SoeArphsRU+T8XofxfL
+vRHkM3JURUjIVZdAQNvxxBso8NJG5KayP0Q96Vw+3sEwFK49jt14RCJy4IkAlQMF
+EDNzvb1sq+iWcxFJBQEBfZwD/R3KNFf9ype9Dea8j1YIeNZ1E3e03en1I8fMj6Em
+S1/L1WfFzMnfFCxZs7JgPtkBuB3CqP8f+LOdDt6PHPqNakmI9E6fiuGfJZ3jFZYA
+TXa0XKuIoxIJNKhqkpbF8ixJZFTxFwAAwVYM3+sqr4qQ8FzVc5entxjyxPFNkwJw
+RWV+iQCVAwUQM2aiBQ7tvOdmanQhAQE7LgQAiN6Hz+zd8bh0nO6VizbJxWFRHPbr
+QWnJXGoMYyy88DyszAXC4zRshlyGUDQdHeP/1DFCXDEu78GfDCLaJ1bm25yVR7kL
+xDZaEUQEbWqxfiwuzizAjkaxrW7dBbWILwWqrYF5TXClw+oUU/oIUW4t6t+GpAO1
+8PLYhSMXVYErrAA=
+=EdyZ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
diff --git a/en/handbook/ports/chapter.sgml b/en/handbook/ports/chapter.sgml
index 092d021ad9..59c780838e 100644
--- a/en/handbook/ports/chapter.sgml
+++ b/en/handbook/ports/chapter.sgml
@@ -1,4523 +1,4673 @@
Installing Applications: The Ports collectionContributed by &a.jraynard;.The FreeBSD Ports collection allows you to compile and install a
very wide range of applications with a minimum of effort.For all the hype about open standards, getting a program to work
on different versions of Unix in the real world can be a tedious and
tricky business, as anyone who has tried it will know. You may be
lucky enough to find that the program you want will compile cleanly on
your system, install itself in all the right places and run flawlessly
“out of the box”, but this is unfortunately rather rare. With most
programs, you will find yourself doing a fair bit of head-scratching,
and there are quite a few programs that will result in premature
greying, or even chronic alopecia...Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but
they have an unfortunate tendency to triumphantly announce that your
system is something you have never heard of and then ask you lots of
questions that sound like a final exam in system-level Unix
programming (Does your system's gethitlist function return a const
pointer to a fromboz or a pointer to a const fromboz? Do you have
Foonix style unacceptable exception handling? And if not, why
not?).Fortunately, with the Ports collection, all the hard work
involved has already been done, and you can just type make install
and get a working program.Why Have a Ports Collection?The base FreeBSD system comes with a very wide range of tools
and system utilities, but a lot of popular programs are not in the
base system, for good reasons:-Programs that some people cannot live without and other
people cannot stand, such as a certain Lisp-based editor.Programs which are too specialised to put in the base
system (CAD, databases).Programs which fall into the “I must have a look at that
when I get a spare minute” category, rather than
system-critical ones (some languages, perhaps).Programs that are far too much fun to be supplied with a
serious operating system like FreeBSD ;-)However many programs you put in the base system, people
will always want more, and a line has to be drawn somewhere
(otherwise FreeBSD distributions would become absolutely
enormous).Obviously it would be unreasonable to expect everyone to port
their favourite programs by hand (not to mention a tremendous amount
of duplicated work), so the FreeBSD Project came up with an
ingenious way of using standard tools that would automate the
process.Incidentally, this is an excellent illustration of how “the
Unix way” works in practice by combining a set of simple but very
flexible tools into something very powerful.How Does the Ports Collection Work?Programs are typically distributed on the Internet as a
tarball consisting of a
Makefile and the source code for the program and usually some
instructions (which are unfortunately not always as instructive as
they could be), with perhaps a configuration script.The standard scenario is that you FTP down the tarball, extract
it somewhere, glance through the instructions, make any changes
that seem necessary, run the configure script to set things up and
use the standard make program to compile and install the program
from the source.FreeBSD ports still use the tarball mechanism, but use a
skeleton to hold the
"knowledge" of how to get the program working on FreeBSD,
rather than expecting the user to be able to work it out. They also
supply their own customised
Makefile, so that almost
every port can be built in the same way.If you look at a port skeleton (either on your FreeBSD
system or the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about Getting a port).“How on earth can this do anything?” I hear you cry. “There
is no source code there!”Fear not, gentle reader, all will become clear (hopefully).
Let's see what happens if we try and install a port. I have chosen
ElectricFence, a useful tool for developers, as the skeleton is
more straightforward than most.If you are trying this at home, you
will need to be root.&prompt.root; cd /usr/ports/devel/ElectricFence
&prompt.root; make install
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
===> Extracting for ElectricFence-2.0.5
===> Patching for ElectricFence-2.0.5
===> Applying FreeBSD patches for ElectricFence-2.0.5
===> Configuring for ElectricFence-2.0.5
===> Building for ElectricFence-2.0.5
[lots of compiler output...]
===> Installing for ElectricFence-2.0.5
===> Warning: your umask is "0002". If this is not desired, set it to
an appropriate value and install this port again by ``make reinstall''.
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
===> Compressing manual pages for ElectricFence-2.0.5
===> Registering installation for ElectricFence-2.0.5To avoid confusing the issue, I have completely removed the
build output.If you tried this yourself, you may well have got something like
this at the start:-&prompt.root; make install
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.The make program has noticed that you did not have a local
copy of the source code and tried to FTP it down so it could get the
job done. I already had the source handy in my example, so it did
not need to fetch it.Let's go through this and see what the make program was
doing.Locate the source code tarball. If it is not available locally, try to
grab it from an FTP site.Run a checksum
test on the tarball to make sure it has not been tampered
with, accidentally truncated, downloaded in ASCII mode, struck
by neutrinos while in transit, etc.Extract the tarball into a temporary work directory.Apply any patches
needed to get the source to compile and run under FreeBSD.Run any configuration script required by the build
process and correctly answer any questions it asks.(Finally!) Compile the code.Install the program executable and other supporting
files, man pages, etc. under the
/usr/local hierarchy, where they will not
get mixed up with system programs. This also makes sure that
all the ports you install will go in the same place, instead
of being flung all over your system.Register the installation in a database. This means that,
if you do not like the program, you can cleanly remove all traces of it from
your system.Scroll up to the make output and see if you can match these
steps to it. And if you were not impressed before, you should be by
now!Getting a FreeBSD PortThere are two ways of getting hold of the FreeBSD port for a
program. One requires a FreeBSD
CDROM, the other involves using an Internet Connection.Compiling ports from CDROMAssuming that your FreeBSD CDROM is in the drive and mounted on
/cdrom (and the mount point
must be /cdrom), you should
then be able to build ports just as you normally do and the port
collection's built in search path should find the tarballs in
/cdrom/ports/distfiles/ (if they exist there)
rather than downloading them over the net.
-
+
+ Another way of doing this, if you want to just use the port
+ skeletons on the CDROM, is to set these variables in
+ /etc/make.conf:
+
+
+PORTSDIR= /cdrom/ports
+DISTDIR= /tmp/distfiles
+WRKDIRPREFIX= /tmp
+
+ Substitute /tmp for any place you have enough
+ free space. Then, just cd to the appropriate
+ subdirectory under /cdrom/ports and type
+ make install as
+ usual. WRKDIRPREFIX will cause the port to be
+ build under /tmp/cdrom/ports; for instance,
+ games/oneko will be built under
+ /tmp/cdrom/ports/games/oneko.
+
There are some ports for which we cannot provide the
original source in the CDROM due to licensing limitations. In
that case, you will need to look at the section on Compiling ports using an Internet connection.Compiling ports from the InternetIf you do not have a CDROM, or you want to make sure you get
the very latest version of the port you want, you will need to
download the
skeleton for the port. Now
this might sound like rather a fiddly job full of pitfalls, but
it is actually very easy.First, if you are running a release version of FreeBSD, make
sure you get the appropriate “upgradekiet” for your
replease from the ports
web page. These packages include files that have been
updated since the release that you may need to compile new
ports.The key to the skeletons is that the FreeBSD FTP server can create
on-the-fly
tarballs for you. Here is
how it works, with the gnats program in the databases directory as
an example (the bits in square brackets are comments. Do not type
them in if you are trying this yourself!):-&prompt.root; cd /usr/ports
&prompt.root; mkdir databases
&prompt.root; cd databases
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports/databases
+>cd /pub/FreeBSD/ports/ports/databases>get gnats.tar
[tars up the gnats skeleton for us]
>quit
&prompt.root; tar xf gnats.tar
[extract the gnats skeleton]
&prompt.root; cd gnats
&prompt.root; make install
[build and install gnats]What happened here? We connected to the FTP server in the
usual way and went to its databases sub-directory. When we gave it
the command get gnats.tar, the FTP server tarred up the gnats directory for us.We then extracted the gnats skeleton and went into the gnats
directory to build the port. As we explained earlier, the make process noticed we did not have a
copy of the source locally, so it fetched one before extracting,
patching and building it.Let's try something more ambitious now. Instead of getting a
single port skeleton, let's get a whole sub-directory, for example
all the database skeletons in the ports collection. It looks
almost the same:-&prompt.root; cd /usr/ports
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports
+>cd /pub/FreeBSD/ports/ports>get databases.tar
[tars up the databases directory for us]
>quit
&prompt.root; tar xf databases.tar
[extract all the database skeletons]
&prompt.root; cd databases
&prompt.root; make install
[build and install all the database ports]With half a dozen straightforward commands, we have now got a
set of database programs on our FreeBSD machine! All we did that
was different from getting a single port skeleton and building it
was that we got a whole directory at once, and compiled everything
in it at once. Pretty impressive, no?If you expect to be installing many ports, it is probably
worth downloading all the ports directories.SkeletonsA team of compulsive hackers who have forgotten to eat in a
frantic attempt to make a deadline? Something unpleasant lurking in
the FreeBSD attic? No, a skeleton here is a minimal framework that
supplies everything needed to make the ports magic work.MakefileThe most important component of a skeleton is the Makefile.
This contains various statements that specify how the port should
be compiled and installed. Here is the Makefile for
ElectricFence:-
# New ports collection makefile for: Electric Fence
# Version required: 2.0.5
# Date created: 13 November 1997
# Whom: jraynard
#
# $Id$
#
DISTNAME= ElectricFence-2.0.5
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SUNSITE}
MASTER_SITE_SUBDIR= devel/lang/c
MAINTAINER= jraynard@freebsd.org
MAN3= libefence.3
do-install:
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
.include <bsd.port.mk>The lines beginning with a "#" sign are comments for
the benefit of human readers (as in most Unix script
files).DISTNAME specifies the name of the tarball, but without the
extension.CATEGORIES states what kind of program this is. In
this case, a utility for developers. See the categories section of this
handbook for a complete list.MASTER_SITES is the URL(s) of the master FTP site,
which is used to retrieve the tarball if it is not available on the local system.
This is a site which is regarded as reputable, and is normally the
one from which the program is officially distributed (in so far
as any software is "officially" distributed on the
Internet).MAINTAINER is the email address of the person who is
responsible for updating the skeleton if, for example a new
version of the program comes out.Skipping over the next few lines for a minute, the line
.include <bsd.port.mk> says
that the other statements and commands needed for this port are
in a standard file called bsd.port.mk. As
these are the same for all ports, there is no point in duplicating
them all over the place, so they are kept in a single standard
file.This is probably not the place to go into a detailed
examination of how Makefiles work; suffice it to say that the line
starting with MAN3 ensures that the ElectricFence man page is
compressed after installation, to help conserve your precious disk
space. The original port did not provide an install target,
so the three lines from do-install ensure that the files
produced by this port are placed in the correct
destination.The files directoryThe file containing the checksum for the port is called
md5, after the MD5 algorithm used for ports
checksums. It lives in a directory with the slightly confusing
name of files.This directory can also contain other miscellaneous files that
are required by the port and do not belong anywhere else.The patches directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The pkg directoryThis program contains three quite useful files:-COMMENT — a one-line description of
the program.DESCR — a more detailed description.PLIST — a list of all the files
that will be created when the program is installed.What to do when a port does not work.Oh. You can do one of four (4) things :Fix it yourself. Technical details on how ports work can
be found in
Porting applications.Gripe. This is done by e-mail only! Send such e-mail to
the &a.ports; and please include the name/version of the port,
where you got both the port source & distfile(s) from, and
what the text of the error was.Forget it. This is the easiest for most — very few of the
programs in ports can be classified as essential!Grab the pre-compiled package from a ftp server. The
“master” package collection is on FreeBSD's FTP server in
the packages
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/">packages
directory, though check your local mirror first,
please! These are more likely to work (on the whole) than
trying to compile from source and a lot faster besides! Use
the pkg_add1 program to install a
package file on your system.Some Questions and AnswersQ. I thought this was going to be a discussion about
modems??!A. Ah. You must be thinking of the serial ports on the
back of your computer. We are using “port” here to mean the
result of “porting” a program from one version of Unix to
another. (It is an unfortunate bad habit of computer people to
use the same word to refer to several completely different
things).Q. I thought you were supposed to use packages to install
extra programs?A. Yes, that is usually the quickest and easiest way of
doing it.Q. So why bother with ports then?A. Several reasons:-The licensing conditions on some software
distributions require that they be distributed as source
code, not binaries.Some people do not trust binary distributions. At
least with source code you can (in theory) read through
it and look for potential problems yourself.If you have some local patches, you will need the
source to add them yourself.You might have opinions on how a program should be
compiled that differ from the person who did the package
— some people have strong views on what optimisation
setting should be used, whether to build debug versions
and then strip them or not, etc. etc.Some people like having code around, so they can
read it if they get bored, hack around with it, borrow
from it (licence terms permitting, of course!) and so
on.If you ain't got the source, it ain't software!
;-) Q. What is a patch?A. A patch is a small (usually) file that specifies how to
go from one version of a file to another. It contains text
that says, in effect, things like “delete line 23”, “add
these two lines after line 468” or “change line 197 to
this”. Also known as a “diff”, since it is generated by a
program of that name. Q. What is all this about
tarballs?A. It is a file ending in .tar or
.tar.gz (with variations like
.tar.Z, or even .tgz
if you are trying to squeeze the names into a DOS
filesystem).Basically, it is a directory tree that has been archived
into a single file (.tar) and optionally
compressed (.gz). This technique was
originally used for Tape
ARchives (hence the name tar), but it is
a widely used way of distributing program source code around
the Internet.You can see what files are in them, or even extract them
yourself, by using the standard Unix tar program, which comes
with the base FreeBSD system, like this:-&prompt.user; tar tvzf foobar.tar.gz
&prompt.user; tar xzvf foobar.tar.gz
&prompt.user; tar tvf foobar.tar
&prompt.user; tar xvf foobar.tar Q. And a checksum?A. It is a number generated by adding up all the data in
the file you want to check. If any of the characters change,
the checksum will no longer be equal to the total, so a simple
comparison will allow you to spot the difference. (In
practice, it is done in a more complicated way to spot
problems like position-swapping, which will not show up with a
simplistic addition).Q. I did what you said for compiling ports from a CDROM and it worked great
until I tried to install the kermit port:-&prompt.root; make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.Why can it not be found? Have I got a dud CDROM?A. The licensing terms for kermit do not allow us to put
the tarball for it on the CDROM, so you will have to fetch it
by hand — sorry! The reason why you got all those error
messages was because you were not connected to the Internet at
the time. Once you have downloaded it from any of the sites
above, you can re-start the process (try and choose the
nearest site to you, though, to save your time and the
Internet's bandwidth).Q. I did that, but when I tried to put it into
/usr/ports/distfiles I got some error
about not having permission.A. The ports mechanism looks for the tarball in
/usr/ports/distfiles, but you will not be
able to copy anything there because it is sym-linked to the
CDROM, which is read-only. You can tell it to look somewhere
else by doing&prompt.root; make DISTDIR=/where/you/put/it installQ. Does the ports scheme only work if you have everything
in /usr/ports? My system administrator
says I must put everything under
/u/people/guests/wurzburger, but it does
not seem to work.A. You can use the PORTSDIR and PREFIX variables to tell
the ports mechanism to use different directories. For
instance,&prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports installwill compile the port in
/u/people/guests/wurzburger/ports and
install everything under /usr/local.&prompt.root; make PREFIX=/u/people/guests/wurzburger/local installwill compile it in /usr/ports and
install it in
/u/people/guests/wurzburger/local.And of course&prompt.root; make PORTSDIR=.../ports PREFIX=.../local installwill combine the two (it is too long to fit on the page if
I write it in full, but I am sure you get the idea).If you do not fancy typing all that in every time you
install a port (and to be honest, who would?), it is a good
idea to put these variables into your environment.Q. I do not have a FreeBSD CDROM, but I would like to have
all the tarballs handy on my system so I do not have to wait
for a download every time I install a port. Is there an easy
way to get them all at once?A. To get every single tarball for the ports collection,
do&prompt.root; cd /usr/ports
&prompt.root; make fetchFor all the tarballs for a single ports directory,
do&prompt.root; cd /usr/ports/directory
&prompt.root; make fetchand for just one port — well, I think you have guessed
already.Q. I know it is probably faster to fetch the tarballs from
one of the FreeBSD mirror sites close by. Is there any way to
tell the port to fetch them from servers other than ones
listed in the MASTER_SITES?A. Yes. If you know, for example, ftp.FreeBSD.ORG is much
closer than sites listed in MASTER_SITES, do as following
example.&prompt.root; cd /usr/ports/directory
-&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
+&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetchQ. I want to know what files make is going to need before
it tries to pull them down.A. make fetch-list will display a list of the files
needed for a port.Q. Is there any way to stop the port from compiling? I
want to do some hacking on the source before I install it, but
it is a bit tiresome having to watch it and hit control-C
every time.A. Doing make extract will stop it after it has fetched
and extracted the source code.Q. I am trying to make my own port and I want to be able
to stop it compiling until I have had a chance to see if my
patches worked properly. Is there something like make
extract, but for patches?A. Yep, make patch is what you want. You will probably
find the PATCH_DEBUG option useful as well. And by the way,
thank you for your efforts!Q. I have heard that some compiler options can cause bugs.
Is this true? How can I make sure that I compile ports with
the right settings?A. Yes, with version 2.6.3 of gcc (the version shipped
with FreeBSD 2.1.0 and 2.1.5), the option could result in
buggy code unless you used the option as
well. (Most of the ports don't use ). You
should be able to specify the compiler
options used by something like&prompt.root; make CFLAGS='-O2 -fno-strength-reduce' installor by editing /etc/make.conf, but
unfortunately not all ports respect this. The surest way is to
do make configure, then go into the source directory and
inspect the Makefiles by hand, but this can get tedious if the
source has lots of sub-directories, each with their own
Makefiles.Q. There are so many ports it is hard to find the one I
want. Is there a list anywhere of what ports are available?A. Look in the INDEX file in
/usr/ports. If you would like to search the
ports collection for a keyword, you can do that too. For example,
you can find ports relevant to the LISP programming language
using:&prompt.user; cd /usr/ports
&prompt.user; make search key=lispQ. I went to install the foo port but the system
suddenly stopped compiling it and starting compiling the
bar
port. What's going on?A. The foo port needs something that is supplied with
bar — for instance, if foo uses graphics, bar might have
a library with useful graphics processing routines. Or bar
might be a tool that is needed to compile the foo
port. Q. I installed the grizzle
program from the ports and frankly it is a complete waste of
disk space. I want to delete it but I do not know where it put
all the files. Any clues?A. No problem, just do&prompt.root; pkg_delete grizzle-6.5
Q. Hang on a minute, you have to know the version number to
use that command. You do not seriously expect me to remember
that, do you??A. Not at all, you can find it out by doing&prompt.root; pkg_info -a | grep grizzle
Information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.Q. Talking of disk space, the ports directory seems to be
taking up an awful lot of room. Is it safe to go in there and
delete things?A. Yes, if you have installed the program and are fairly
certain you will not need the source again, there is no point
in keeping it hanging around. The best way to do this
is&prompt.root; cd /usr/ports
&prompt.root; make cleanwhich will go through all the ports subdirectories and
delete everything except the skeletons for each port.Q. I tried that and it still left all those tarballs or
whatever you called them in the distfiles
directory. Can I delete those as well?A. Yes, if you are sure you have finished with them, those
can go as well.Q. I like having lots and lots of programs to play with.
Is there any way of installing all the ports in one go?A. Just do&prompt.root; cd /usr/ports
&prompt.root; make installQ. OK, I tried that, but I thought it would take a very
long time so I went to bed and left it to get on with it. When
I looked at the computer this morning, it had only done three
and a half ports. Did something go wrong?A. No, the problem is that some of the ports need to ask
you questions that we cannot answer for you (eg “Do you want
to print on A4 or US letter sized paper?”) and they need to
have someone on hand to answer them.Q. I really do not want to spend all day staring at the
monitor. Any better ideas?A. OK, do this before you go to bed/work/the local
park:-&prompt.root cd /usr/ports
&prompt.root; make -DBATCH installThis will install every port that does
not require user input. Then, when you
come back, do&prompt.root; cd /usr/ports
&prompt.root; make -DIS_INTERACTIVE installto finish the job.Q. At work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do
what we need. Is there any way of making our own packages, so
we can distribute it more easily around our sites?A. No problem, assuming you know how to make patches for
your changes:-&prompt.root; cd /usr/ports/somewhere/frobble
&prompt.root; make extract
&prompt.root; cd work/frobble-2.8
[Apply your patches]
&prompt.root; cd ../..
&prompt.root; make packageQ. This ports stuff is really clever. I am desperate to
find out how you did it. What is the secret?A. Nothing secret about it at all, just look at the
bsd.ports.mk and
bsd.ports.subdir.mk files in your makefiles
directory.Readers with an aversion to intricate shell-scripts are
advised not to follow this link...)Making a port yourselfContributed by &a.jkh;, &a.gpalmer;, &a.asami;
&a.obrien; and &a.hoek;. 28 August 1996.So, now you are interested in making your own port?
Great!What follows are some guidelines for creating a new port for
FreeBSD. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Only a fraction of the overridable variables
(VAR) are mentioned
in this document. Most (if not all) are documented at the start of
bsd.port.mk. This file users a non-standard
tab setting. Emacs and
Vim should recognise the setting on
loading the file. vi or ex
can be set to use the correct value by typing :set
tabstop=4 once the file has been loaded.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into DISTDIR, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the MakefileThe minimal Makefile would
look something like this:
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# $Id$
#
DISTNAME= oneko-1.1b
CATEGORIES= games
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG
MAN1= oneko.1
MANCOMPRESSED= yes
USE_IMAKE= yes
.include <bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the sample Makefile
section.Writing the description filesThere are three description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.COMMENTThis is the one-line description of the port.
Please do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the screen.DESCRThis is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual or an
in-depth description on how to use or compile the port!
Please be careful if you are copying from the
README or manpage; too often
they are not a concise description of the port or are in an
awkward format (e.g., manpages have justified spacing). If the
ported software has an official WWW homepage, you should list
it here.It is recommended that you sign the name at the end of
this file, as in:
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
http://www.oneko.org/
- Satoshi
asami@cs.berkeley.eduPLISTThis file lists all the files installed by the port. It
is also called the “packing list” because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). If you are using the
MANn variables (as
you should be), do not list any manpages here.Here is a small example:
bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/onekoRefer to the pkg_create1 man page
for details on the packing list.You should list all the files, but not the name
directories, in the list. Also, if the port creates
directories for itself during installtion, make sure to add
@dirrm lines as necessary to remove them
when the port is deleted.It is recommended that you keep all the filenames in
this file sorted alphabetically. It will make verifying the
changes when you upgrade the port much easier.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. These are
the important points you need to verify.PLIST does not contain anything not
installed by your portPLIST contains everything that is
installed by your portYour port can be installed multiple times using the
reinstall targetYour port cleans
up after itself upon deinstallRecommended test orderingmake installmake packagemake deinstallpkg_add `make package-name`make deinstallmake reinstallmake packageMake sure that there aren't any warnings issued in any of
the package and
deinstall stages, After step 3, check
to see if all the new directories are correctly deleted. Also,
try using the software after step 4, to ensure that is works
correctly when installed from a package.Checking your port with portlintPlease use portlint to see if your port
conforms to our guidelines. The portlint
program is part of the ports collection. In particular, your may
want to check if the Makefile is in the right
shape and the package is
named appropriately.Submitting the portFirst, make sure you have read the Do's and Dont's section.Now that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. We do not need your
work directory or the
pkgname.tgz package, so delete them
now. Next, simply include the output of shar `find
port_dir` in a bug report and send it with the
send-pr1 program (see Bug
Reports and General Commentary for more information
about send-pr1. If the uncompressed port is larger than
20KB, you should compress it into a tarfile and use uuencode1 before including it in the bug report (uuencoded
tarfiles are acceptable even if the bug report is smaller than
20KB but are not preferred). Be sure to classify the bug report as
category ports and class
change-request. (Do not mark the report
confidential!)One more time, do not include the original source
distfile, the work directory, or the
package you built with make
package.In the past, we asked you to upload new port submissions
in our ftp site (ftp.freebsd.org). This is no longer
recommended as read access is turned off on that
incoming/ directory of that site due to
the large amount of pirated software showing up there.We will look at your port,
get back to you if necessary, and put it in the
tree. Your name will also appear in the list of “Additional
FreeBSD contributors” on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in DISTDIR.
If fetch cannot find the required files in DISTDIR it will look up the
URL MASTER_SITES,
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
The extract target is run. It looks for your port's
distribution file (typically a gzip'd tarball) in DISTDIR and unpacks it into a temporary subdirectory
specified by WRKDIR
(defaults to work).The patch target is run. First, any patches defined
in PATCHFILES are
applied. Second, if any patches are found in PATCHDIR (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.The configure target is run. This can do any one of
many different things.If it exists,
scripts/configure is run.If HAS_CONFIGURE or
GNU_CONFIGURE
is set,
WRKSRC/configure is
run.If USE_IMAKE is set,
XMKMF
(default: xmkmf
-a) is run.The build target is run. This is responsible for
- descending into the ports' private working directory
+ descending into the port's private working directory
(WRKSRC) and
building it. If USE_GMAKE is set, GNU
make will be used,
otherwise the system make
will be used.The above are the default actions. In addition, you can
define targets pre-something or post-something, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-something. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-something target in
your Makefile.The “main” targets (e.g., extract, configure, etc.) do nothing more than
- make sure all the stages up to that one is completed and
+ make sure all the stages up to that one are completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (foo.tar.gz or
foo.tar.Z) and copy it into
DISTDIR. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, you might want to put a copy on a
reliable ftp or http server that you control (e.g., your home
page). Make sure you set MASTER_SITES to
reflect your choice.If you
cannot find somewhere convenient and reliable to put the distfile
(if you are a FreeBSD committer, you can just put it in your
public_html/ directory on
freefall),
we can “house” it ourselves by putting
- it on ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
+ it on ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as MASTER_SITE_LOCAL. Send mail to
the &a.ports;if you are not sure what to do.If your port's distfile changes all the time for no good
reason, consider putting the distfile in your home page and
listing it as the first MASTER_SITES. This
will prevent users from getting checksum
mismatch errors, and also reduce the workload of
maintainers of our ftp site. Also, if there isonly one master
site for the port, it is recommended that you house a backup at
your site and list it as the second
MASTER_SITES.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
DISTDIR. Do not worry if
- they come from site other than where you got the main source
+ they come from a site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of PATCHFILES below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as “plug-and-play”
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-xx where
xx denotes the sequence in which
the patches will be applied — these are done in
alphabetical order, thus
aa first, ab second and so on. These files
should be stored in PATCHDIR, from where they will be
automatically applied. All patches should be relative to
WRKSRC (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier,
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing WRKSRC/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow “overnight builds” to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).It is also recommended that if there are reasonable default
answers to the questions, you check the
PACKAGE_BUILDING variable and turn off the
interactive script when it is set. This will allow us to build
the packages for CD-ROMs and ftp.Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a sample
Makefile in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in DISTDIR as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set DISTNAME to be the base name of
your port. The default rules expect the distribution file
list (DISTFILES) to be
named DISTNAMEEXTRACT_SUFX which, if it is a normal tarball, is going to be
something like foozolix-1.0.tar.gz for a setting of DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/DISTNAME, e.g. work/foozolix-1.0/.All this behavior can be overridden, of course; it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set DISTFILES explicitly. If only a
subset of DISTFILES are
actual extractable archives, then set them up in EXTRACT_ONLY, which will override
the DISTFILES list when
it comes to extraction, and the rest will be just left in
DISTDIR for later
use.PKGNAMEIf DISTNAME does not conform to our guidelines for a good package
name, you should set the PKGNAME
variable to something better. See the abovementioned guidelines
for more details.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable CATEGORIES. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories and pick the
ones that are suitable for your port.This list also determines where in the ports tree the port
is imported. If you put more than one category here, it is
assumed that the port files will be put in the subdirectory with
the name in the first category. See the categories section for
more discussion about how to pick the right categories.If you port truly belongs to something that is different
from all the existing ones, you can even create a new category
name. In that case, please send mail to the &a.ports; to propose
a new category.There is no error checking for category
names. make package will happily create a
new directory if you mustype the category name, so be
careful!MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in MASTER_SITES. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with FETCH if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set PATCHFILES to the names of the
files and PATCH_SITES to
the URL of the directory that contains them (the format is the
same as MASTER_SITES).If the patch is not relative to the top of the source tree
(i.e., WKRSRC) because it
contains some extra pathnames, set PATCH_DIST_STRIP accordingly.
- For instance, if all the pathnames in the patch has an extra
+ For instance, if all the pathnames in the patch have an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
PATCHFILES. If that is
the case, add the name and the location of the patch tarball
to DISTFILES and
MASTER_SITES. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the PATCHDIR directory and calling it
patch-xx.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to MAINTAINER
on Makefiles section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine. There are also some
pre-supported dependency variables for common cases, plus a few
more to control the behaviour of dependencies.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir:target tuples where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available, and
target is the target to call in
that directory. For example,
LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install
will check for a shared jpeg library with
major version 9, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found. The target part can be
omitted if it is equal to DEPENDS_TARGET
(which defaults to install).The lib part is an argument
given to ldconfig -r | grep -wF. There
shall be no reqular expressions in this variable.The dependency is checked twice, once from within the
extract target and then from within
the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir:target tuples where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available, and
target is the target to call in
that directory. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
will check if the file or directory
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish8.0 is in your search path, and
descend into the x11-toolkits/tk80 subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system. The
target part can be omitted if it is
the same DEPENDS_TARGET.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir:target tuples.
For example,
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.“build” here means everything from extracting to
compilation. The dependency is checked from within the
extract target. The
target part can be omitted if it
is the same as DEPENDS_TARGETFETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir:target tuples. For
example,
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the
fetch target. The
target part can be omitted if it is
the same as DEPENDS_TARGET.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted in addition to having
them installed, then use this variable. This is a list of
dir:target, as there is nothing to check, unlike the previous four. The target part can be omitted if it is the same as DEPENDS_TARGET.Common dependency variablesDefine USE_XLIB=yes if your port
requires the X Window System to be installed (it is implied by
USE_IMAKE). Define
USE_GMAKE=yes if your port requires GNU
make instead of BSD
make. Define
USE_AUTOCONF=yes if your port requires GNU
autoconf to be run. Define USE_QT=yes if
your port uses the latest qt toolkit. Use
USE_PERL5=yes if your port requires version
5 of the perl language. (The last is especially important since
some versions of FreeBSD has perl5 as part of the base system
while others don't.)Notes on dependenciesAs mentioned above, the default target to call when a
dependency is required is
DEPENDS_TARGET. It defaults to
install. This is a user variable; is is
never defined in a port's Makefile. If
your port needs a special way to handle a dependency, use the
:target part of the
*_DEPENDS variables instead of redefining
DEPENDS_TARGET.When you type make clean, its
dependencies are automatically cleaned too. If you do not wish
this to happen, define the variable
NOCLEANDEPENDS in your environment.To depend on another port unconditionally, it is customary
to use the string nonexistent as the first
field of BUILD_DEPENDS or
RUN_DEPENDS. Use this only when you need to
the to get to the source of the other port. You can often save
compilation time by specifying the target too. For
instance
BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract
will always descend to the JPEG port and extract it.Do not use DEPENDS unless there is no
other way the behaviour you want can be accomplished. It will
cause the other port to be always build (and installed, by
default), and the dependency will go into the packages as
- well. If this is really what you need, I recommend you to
+ well. If this is really what you need, I recommend you
write it as BUILD_DEPENDS and
RUN_DEPENDS instead—at least the
intention will be clear.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses
configure, set
HAS_CONFIGURE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes (this implies
HAS_CONFIGURE). If you want to give some
extra arguments to configure (the default
argument list --prefix=${PREFIX} for
GNU configure and empty for non-GNU
configure), set those extra arguments in
CONFIGURE_ARGS. If your package uses GNU
autoconf, set
USE_AUTOCONF=yes. This implies
GNU_CONFIGURE, and will cause
autoconf to be run before
configure.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.
If the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>If your port's source Makefile has
something else than all as the main
build target, set ALL_TARGET
accordingly. Same goes for install and
INSTALL_TARGET.Special considerationsThere are some more things you have to take into account when
you create a port. This section explains the most common of
those.ldconfigIf your port installs a shared library, add a
post-install target to your
Makefile that runs
${LDCONFIG} -m on the directory where
the new library is installed (usually
PREFIX/lib) to register
it into the shared library cache.Also, add a matching @exec /sbin/ldconfig
-m and @unexec /sbin/ldconfig -R
pair to your pkg/PLIST file so that a user
who installed the package can start using teh shared libraru
immediately and deinstallation will not cause the system to
still believe the library is there. These lines should
immediately follow the line for the shared library itself, as
in:
lib/libtvl80.so.1
@exec /sbin/ldconfig -m %D/lib
@unexec /sbin/ldconfig -RNever, ever, ever add a line that says
ldconfig without any arguments to your
Makefile or
pkg/PLIST. This will reset the shared
libraru cache to the contents of /usr/lib
only, and will royally screw up the user's machine ("Help, xinit
does not run anymore after I install this port!"). Anybody who
does this will be shot and cut in 65,536 pieces by a rusty knife
and have is liver chopped out by a bunch of crows and will
eternally rot to death in the deepest bowels of hell (not
necessarily in that order…)ELF support
- Since FreeBSD is moving to ELF from 3.0-release onwards,
+ Since FreeBSD is moving to ELF shortly after 3.0-release,
we need to convert many ports that build shared libraries
to support ELF. Complicating this task is that a 3.0
system can run as both ELF and a.out, and that there will
be one more release (2.2.8) from the 2.2 branch. Below
are the guidelines on how to convert a.out only ports to
support both a.out and ELF compilation.Some part of this list is only applicable during the
conversion, but will be left here for awhile for reference
in case you have come across some old port you wish to
upgrade.Moving a.out libraries out of the wayA.out libraries should be moved out of
/usr/local/lib and similar to an
aout subdirectory. (If you don't move them
out of the way, ELF ports will happily overwrite a.out libraries.)
The move-aout-libs target in the -current
src/Makefile (called from
aout-to-elf) will do this for you. It
will only move a.out libs so it is safe to call it on a system
with both ELF and a.out libs in the standard directories.FormatThe ports tree will build packages in the format the machine
is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending
on what `objformat` returns. Also, once users
move a.out libraries to a subdirectory, building a.out libraries
will be unsupported. (I.e., it may still work if you know what you
are doing, but you are on your own.)If a port only works for a.out, set
BROKEN_ELF to a string describing the reason
why. Such ports will be skipped during a build on an ELF
system.PORTOBJFORMATbsd.port.mk will set
PORTOBJFORMAT to aout or
elf and export it in the environments
CONFIGURE_ENV, SCRIPTS_ENV and
MAKE_ENV. (It's always going to be
aout in -stable). It is also passed to
PLIST_SUB as
PORTOBJFORMAT=${PORTOBJFORMAT}. (See comment
on ldconfig lines below.)The variable is set using this line in
bsd.port.mk:
PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aoutPorts' make processes should use this variable to decide what
to do. However, if the port's configure
script already automatically detects an ELF system, it is not
necessary to refer to PORTOBJFORMAT.Building shared librariesThe following are differences in handling shared
libraries for a.out and ELF.Shared library versionsAn ELF shared library should be called
libfoo.so.M
where M is the single version
number, and an a.out library should be called
libfoo.so.M.N where M is the major version and N is the the minor version number. Do not mix those; never install an ELF shared library called libfoo.so.N.M or an a.out shared library (or symlink) called libfoo.so.N.Linker command linesAssuming cc -shared is used rather than
ld directly, the only difference is that
you need to add
on the command line for ELF.You need to install a symlink from
libfoo.so to
libfoo.so.N to
make ELF linkers happy. Since it should be listed in
PLIST too, and it won't hurt in the a.out
case (some ports even require the link for dynamic loading), you
should just make this link regardless of the setting of
PORTOBJFORMAT.LIB_DEPENDSAll port Makefiles are edited to remove minor numbers from
LIB_DEPENDS, and also to have the regexp
support removed. (E.g., foo\\.1\\.\\(33|40\\)
becomes foo.2.) They will be matched using
grep -wF.PLISTPLIST should contain the short (ELF)
shlib names if the a.out minor number is zero, and the long
(a.out) names otherwise. bsd.port.mk will
automatically add .0 to the end of short shlib
lines if PORTOBJFORMAT equals
aout, and will delete the minor number from
long shlib names if PORTOBJFORMAT equals
elf.In cases where you really need to install shlibs with two
versions on an ELF system or those with one version on an a.out
system (for instance, ports that install compatibility libraries
for other operating systems), define the variable
NO_FILTER_SHLIBS. This will turn off the
editing of PLIST mentioned in the previous
paragraph.ldconfigThe ldconfig line in Makefiles should read:
${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....In PLIST it should read;
@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ...
@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -RThis is to ensure that the correct ldconfig
will be called depending on the format of the package, not the
default format of the system.MASTERDIRIf your port needs to build slightly different versions of
packages by having a variable (for instance, resolution, or paper
size) take different values, create one subdirectory per package
to make it easier forusers to see what to do, but try to share as
many files as possible between ports. Typically you only need a
very short Makefile in all but one of the
directories if you use variables cleverly. In the sole
Makefiles, you can use
MASTERDIR to specify the directory where the
rest of the files are. Also, use a variable as part of
PKGNAME
so the packages will have different names.This will be best demonstrated by an example. This is part of
japanese/xdvi300/Makefile;
PKGNAME= ja-xdvi${RESOLUTION}-17
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endifjapanese/xdvi300 also has all the regular
patches, package files, etc. If you type make
there, it will take the default value for the resolution (300) and
build the port normally.As for other resolutions, this is the
entirexdvi118/Makefile;
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile(xdvi240/Makefile and
xdvi400/Makefile are similar). The
MASTERDIR definition tells
bsd.port.mk that the refulat set of
subdirectories like PATCHDIR and
PKGDIR are to be found under
xdvi300. The
RESOLUTION=118 line will override the
RESOLUTION=300 line in
xdvi300/Makefile and the port will be built
with resolution set to 118.Shared library versionsFirst, please read our policy
on shared library versioning to understand
what to do with shared library versions in general. Do
not blindly assume software authors know what they are
doing; many of them do not. It is very important that
these details are carefully considered, as we have quite a
unique situation where we are trying to have dozens of
potentially incompatible software pairs co-exist.
Careless port imports have caused great trouble regarding
shared libraries in the past (ever wondered why the port
jpeg-6b has a shared library version of 9.0?).
If in doubt, send a message to the &a.ports;. Most of the
time, your job ends by determining the right shared
library version and making appropriate patches to
implement it.However, if there is a port which is a different version
of the same software already in the tree, the situation is
much more complex. In short, the FreeBSD implementation
does not allow the user to specify to the linker which
version of shared library to link against (the linker will
always pick the highest numbered version). This means, if
there is a libfoo.so.3.2 and libfoo.so.4.0 in
the system, there is no way to tell the linker to link a
particular application to libfoo.so.3.2. It is
essentially completely overshadowed in terms of
compilation-time linkage. In this case, the only solution
is to rename the base part of the shared library. For
instance, change libfoo.so.4.0 to
libfoo4.so.1.0 so both version 3.2 and 4.0 can be
linked from other ports.ManpagesThe MAN[1-9LN] variables will automatically
add any manpages to pkg/PLIST (this means you
must not list manpages in the
PLIST—see generating PLIST for more). It
also makes the install stage automatically compress or uncompress
manpages depending on the setting of
NOMANCOMPRESS in
/etc/make.conf.To specify whether the manpages are compressed upon
installation, use the MANCOMPRESSED variable.
This variable can take three values, yes,
no and maybe.
yes means manpages are already installed
compressed, no means they are not, and
maybe means the software already respects the
value of NOMANCOMPRESS so
bsd.port.mk does not have to do anything
special.MANCOMPRESSED is automatically set to
yes if USE_IMAKE is set and
NO_INSTALL_MANPAGES is not set, and to
no otherwise. You don't have to explicitly
define it unless the default is not suitable for your port.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages in
certain sections go in a non-standard place, such as some Perl
modules ports, you can set individual man paths using
MANsectPREFIX (where
sect is one of 1-9,
L or N).If your manpages go to language-specific subdirectories, set
the name of the languages to MANLANG. The
value of this variable defaults to "" (i.e.,
English only).Here is an example that puts it all together.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yesThis states that six files are installed by this port;
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gzPorts that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is
a free clone reported to be able to run many applications in
x11-toolkits/lesstif) to compile. Since
it is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically (for people who are compiling from the port) or
statically (for people who distribute packages).REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.MOTIFLIBThis variable will be set by
bsd.port.mk to be the appropriate reference
to the Motif library. Please patch the source to use this
wherever the Motif library is referenced in the
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its Makefile
or Imakefile, simply substitute
${MOTIFLIB} for
it.If the port uses XmClientLibs
in its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands to
-L/usr/X11R6/lib -lXm or
/usr/X11R6/lib/libXm.a, so there is no need
to add -L or -l in
front.X11 fontsIf your port installs fonts for the X Window system, put them
in
X11BASE/lib/X11/fonts/local.
This directory is new to XFree86 release 3.3.3. If it does not
exist, please create it, and print out a message urging the user
to update their XFree86 to 3.3.3 or newer, or at least add this
directory to the font path in
/etc/XF86Config.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info
to add and delete entries to the dir file. If
your port installs any info documents, please follow this
instructions so your port/package will correctly update the user's
PREFIX/info/dir
file. (Sorry for the length of this section, but is it imperative
to weave all the info files together. If done correctly, it will
produce a beautiful listing, so please bear
with me!First, this is what you (as a porter) need to know&prompt.user; install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
:
--entry=TEXT Insert TEXT as an Info directory entry.
:
--section=SEC Put this file's entries in section SEC of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995
+++ ./man/vip.texi Tue May 20 01:28:33 1997
@@ -2,6 +2,10 @@
@setfilename ../info/vip
@settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry
+* VIP: (vip). A VI-emulation for Emacs.
+@end direntry
@iftex
@finalout
:The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/04/15 06:32:12
@@ -15,9 +15,6 @@
man/man1/emacs.1.gz
man/man1/etags.1.gz
man/man1/ctags.1.gz
-@unexec cp %D/info/dir %D/info/dir.bak
-info/dir
-@unexec cp %D/info/dir.bak %D/info/dir
info/cl
info/cl-1
info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+ if [ ! -f ${PREFIX}/info/dir ]; then \
+ ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \
+ fi
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/05/20 10:25:12 1.17
@@ -16,7 +14,15 @@
man/man1/etags.1.gz
man/man1/ctags.1.gz
+@unexec install-info --delete %D/info/emacs %D/info/dir
:
+@unexec install-info --delete %D/info/ccmode %D/info/dir
info/cl
info/cl-1
@@ -87,6 +94,18 @@
info/viper-3
info/viper-4
+@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
+@exec install-info %D/info/emacs %D/info/dir
:
+@exec install-info %D/info/ccmode %D/info/dir
libexec/emacs/19.34/i386--freebsd/cvtmail
libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :). Check the dir file before and after each
step.The pkg/ subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.MESSAGEIf you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capability is often useful to display additional installation
steps to be taken after a pkg_add or to display
licensing information.The pkg/MESSAGE file does not need to
be added to pkg/PLIST. Also, it will not get
automatically printed if the user is using the port, not the
package, so you should probably display it from the
post-install target yourself.INSTALL
- If your port needs execute commands when the binary package is
- installed with pkg_add you can do with via the
+ If your port needs to execute commands when the binary package is
+ installed with pkg_add you can do this via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice by
pkg_add. The first time will as
INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be
tested to determine which mode the script is being run in. The
PKG_PREFIX environmental variable will be set to
the package installation directory. See pkg_add1 for additional
information.This script is not run automatically if you install the port
with make install. If you are depending on
- it being run, you will have to explicitly call it on your port's
+ it being run, you will have to explicitly call it from your port's
Makefile.REQIf your port needs to determine if it should install or not,
you can create a pkg/REQ
“requirements” script. It will be invoked
automatically at installation/deinstallation time to determine
whether or not installation/deinstallation should proceed.Changing PLIST based on make variablesSome ports, particularly the p5- ports, need to change their
PLIST depending on what options they are
configured with (or version of perl, in the case of p5- ports). To
make this easy, any instances in the PLIST of
%%OSREL%%, %%PERL_VER%%, and
%%PERL_VERSION%% will be substituted for
appropriately. The value of %%OSREL%% is the
numeric revision of the operating system (e.g.,
2.2.7). %%PERL_VERSION%% is
the full version number of perl (e.g., 5.00502)
and %%PERL_VER%% is the perl version number
minus the patchlevel (e.g., 5.005).If you need to make other substitutions, you can set the
PLIST_SUB variable with a list of
VAR=VALUE
pairs and instances of
%%VAR%%' will be
substituted with VALUE in the
PLIST.For instance, if you have a port that installs many files in
a version-specific subdirectory, you can put something
like
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
in the Makefile and use
%%OCTAVE_VERSION%% wherever the version shows
up in PLIST. That way, when you upgrade the
port, you will not have to change dozens (or in some cases,
hundreds) of lines in the PLIST.This substitution (as well as addition of any man pages) will be done
between the do-install and
post-install targets, by reading from
PLIST and writing to
TMPPLIST (default:
WRKDIR/.PLIST.mktmp). So
if your port builds PLIST on the fly, do so in
or before do-install. Also, if your port
needs to edit the resulting file, do so in
post-install to a file named
TMPPLIST.
+
+
+ Changing the names of files in the
+ pkg subdirectory
+
+ All the filenames in the pkg subdirectory
+ are defined using variables so you can change them in your
+ Makefile if need be. This is especially useful when you
+ are sharing the same pkg subdirectory among
+ several ports or have to write to one of the above files (see
+ writing to places other than
+ WRKDIR for why it is a bad idea to
+ write directly in to the pkg
+ subdirectory.
+
+ Here is a list of variable names and their default
+ values.
+
+
+
+
+
+ Variable
+ Default value
+
+
+
+
+
+ COMMENT
+ ${PKGDIR}/DESCR
+
+
+
+ DESCR
+ ${PKGDIR}/DESCR
+
+
+
+ PLIST
+ ${PKGDIR}/PLIST
+
+
+
+ PKGINSTALL
+ ${PKGDIR}/PKGINSTALL
+
+
+
+ PKGDEINSTALL
+ ${PKGDIR}/PKGDEINSTALL
+
+
+
+ PKGREQ
+ ${PKGDIR}/REQ
+
+
+
+ PKGMESSAGE
+ ${PKGDIR}/MESSAGE
+
+
+
+
+
+ Please change these variables rather than overriding
+ PKG_ARGS. If you change
+ PKG_ARGS, those files will not correctly be
+ installed in /var/db/pkg upon install from a
+ port.
+
-
+
Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
- can do with them vary a lot, depending on the exact wordings of
+ can do with them varies a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a “do not sell for profit” type of
license, set the variable NO_CDROM to a
string describing the reason why. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE to a string describing the
reason why. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a “no commercial use” license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (e.g., if your modified port
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category ports). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.You should check your own port
against this list, but you can also check ports in the PR
database that others have submitted. Submit any comments on
ports you check as described in Bug
Reports and General Commentary. Checking ports in
the PR database will both make it faster for us to commit them,
and prove that you know what you are doing.Strip BinariesDo strip binaries. If the original source already strips the
binaries, fine; otherwise you should add a
post-install rule to to it yourself. Here is an
example;
post-install:
strip ${PREFIX}/bin/xdlUse the file1 command on the installed executable to check
whether the binary is stripped or not. If it does not say
not stripped, it is stripped.INSTALL_* macrosDo use the macros provided in bsd.port.mk
to ensure correct modes and ownership of files in your own
*-install targets. They are:INSTALL_PROGRAM is a command to install
binary executables.INSTALL_SCRIPT is a command to install
executable scripts.INSTALL_DATA is a command to install
sharable data.INSTALL_MAN is a command to install
manpages and other documentation (it doesn't compress
anything).These are basically the install command
with all the appropriate flags. See below for an example on how
to use them.
+
+
+ WRKDIR
+
+ Do not write anything to files outside
+ WRKDIR. WRKDIR is the only
+ place that is guaranteed to be writable during the port build (see
+ compiling ports from CDROM for an
+ example of building ports from a read-only tree). If you need to
+ modigy some file in PKGDIR, do so by redefining a variable, not by
+ writing over it.
+
+
+
+ WRKDIRPREFIX
+
+ Make sure your port honors
+ WRKDIRPREFIX. Most ports don't have to worry
+ about this. In particular, if you are referring to a
+ WRKDIR of another port, note that the correct
+ location is
+ WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such.
+
+ Also, if you are defining WRKDIR yourself,
+ make sure you prepend
+ ${WKRDIRPREFIX}${.CURDIR} in the
+ front.
+ Differentiating operating systems and OS versionsYou may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as general
as possible so that we can back-port code to FreeBSD 1.x systems
and cross-port to other BSD systems such as 4.4BSD from CSRG,
BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file is
already included; if not, add the code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endifto the proper place in the .c file. We
- believe that every system that defines these to symbols has
+ believe that every system that defines these two symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to the
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile
for this method.Once you have sys/param.h
included, you may use:
#if (defined(BSD) && (BSD >= 199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:
#if (defined(BSD) && (BSD >= 199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is
199506 for the 4.4BSD-Lite2 code base. This is
stated for informational purposes only. It should not be used to
- distinguish between version of FreeBSD based only on 4.4-Lite vs.
+ distinguish between versions of FreeBSD based only on 4.4-Lite vs.
versions that have merged in changes from 4.4-Lite2. The
__FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
only affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endifRelease_FreeBSD_version2.0-RELEASE1194112.1-currents199501, 1995032.0.5-RELEASE1995042.2-current before 2.11995082.1.0-RELEASE1995112.2-current before 2.1.51995122.1.5-RELEASE1996072.2-current before 2.1.61996082.1.6-RELEASE1996122.1.7-RELEASE1996122.2-RELEASE2200002.2.1-RELEASE220000 (no change)2.2-STABLE after 2.2.1-RELEASE220000 (no change)2.2-STABLE after texinfo-3.92210012.2-STABLE after top2210022.2.2-RELEASE2220002.2-STABLE after 2.2.2-RELEASE2220012.2.5-RELEASE2250002.2-STABLE after 2.2.5-RELEASE2250012.2-STABLE after ldconfig -R merge2250022.2.6-RELEASE2260002.2.7-RELEASE2270002.2-STABLE after 2.2.7-RELEASE2270012.2-STABLE after semctl(2) change2270022.2.8-RELEASE2280002.2-STABLE after 2.2.8-RELEASE2280013.0-current before mount(2) change3000003.0-current after mount(2) change3000013.0-current after semctl(2) change3000023.0-current after ioctl arg changes3000033.0-current after ELF conversion3000043.0-RELEASE3000053.0-current after 3.0-RELEASE300006
+
+
+ 3.0-stable after 3/4 branch
+ 300007
+
+
+
+ 3.1-RELEASE
+ 310000
+
+
+
+ 3.1-stable after 3.1-RELEASE
+ 310001
+
+
+
+ 4.0-current after 3/4 branch
+ 400000
+ Note that 2.2-STABLE sometimes identifies itself as
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Writing something after
bsd.port.mkDo not write anything after the .include
<bsd.port.mk> line. it usually can be avoided by
including bsd.port.pre.mk somewhere in the
middle of your Makefile and
bsd.port.post.mk at the end.You need to include either the
pre.mk/post.mk pair or
bsd.port.mk only; don't mix these
two.bsd.port.pre.mk only defines a few
variables, which can be used in tests in the
Makefile,
bsd.port.post.mk defines the rest.Here are some important variables defined in
bsd.port.pre.mk (this is not the complete
list, please read bsd.port.mk for the
complete list).VariableDescriptionARCHThe architecture as returned by uname
-m (e.g., i386)OPSYSThe operating system type, as returned by
uname -s (e.g.,
FreeBSD)OSRELThe release version of the operating system (e.g.,
2.1.5 or
2.2.7)OSVERSIONThe numeric version of the operating system, same as
__FreeBSD_version.PORTOBJFORMATThe object format of the system
(aout or elfLOCALBASEThe base of the “local” tree (e.g.,
/usr/local/)X11BASEThe base of the “X11” tree (e.g.,
/usr/X11R6)PREFIXWhere the port installs itself (see more on
PREFIX).If you have to define the variables
USE_IMAKE, USE_X_PREFIX,
or MASTERDIR, do so before including
bsd.port.pre.mk.Here are some examples of things you can write after
bsd.port.pre.mk;
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endifInstall additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
PREFIX/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means PKGNAME minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole PKGNAME.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)Also you can use the pkg/MESSAGE file to
display messages upon installation. See the using
pkg/MESSAGE section for
details.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
Makefile), set DIST_SUBDIR to the name of the
port (PKGNAME without the
version part should work fine). This will change DISTDIR from the default
/usr/ports/distfiles to
/usr/ports/distfiles/DIST_SUBDIR,
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting DISTDIR explicitly in your
Makefile will not accomplish this, so please use DIST_SUBDIR.)This does not affect the MASTER_SITES you define in your
Makefile.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
NO_PACKAGE is
set.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. If you had to edit
configure.in and run
autoconf to regenerate
configure, do not take the diffs of
configure (it often grows to a few thousand
lines!); define USE_AUTOCONF=yes and take the
diffsof configure.in.Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resulting diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to PREFIX. (The value of this
variable will be set to LOCALBASE (default
/usr/local), unless USE_X_PREFIX or USE_IMAKE is set, in which case it
will be X11BASE (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read PREFIX, as this
variable is automatically passed down to every stage of the
build and install processes.Do not set USE_X_PREFIX unless your port
truly require it (i.e., it links against X libs or it needs to
reference files in X11BASE).The variable PREFIX
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles.Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\"
or
-DPAGER=\"${LOCALBASE}/bin/less\"
if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of PREFIX. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
- details, the rule governing /usr pretty
- much applies to /usr/local too. The
+ details, the rules governing /usr pretty
+ much apply to /usr/local too. The
exception are ports dealing with USENET “news”. They may use
PREFIX/news as a destination for
their files.Cleaning up empty directoriesDo make your ports clean up after themselves when they are
deinstalled. This is usually accomplished by adding
@dirrm lines for all directories that are
specifically created by the port. You need to delete
subdirectories before you can delete parent directories.
:
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
:
@dirrm lib/X11/oneko/pixmals
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/onekoHowever, sometimes @dirrm will give you
errors because other ports also share the same subdirectory. You
can call rmdir from @unexec
to remove only empty directories without warning.
@unexec rmdir %D/share/doc/gimp 2>/dev/null || trueThis will neither print any error messages nor cause
pkg_delete to exit abnormally even if
PREFIX/share/doc/gimp is
not empty due to other ports installing some files in there.UIDsIf your port requires a certain user to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at net/cvsup-mirror
for an example.If your port must use the same user/group ID number when it is
installed a binarypackage as when it was compiled, then you mus
choose a free UID from 50 to 99 and register it below. Look at
japanese/Wnn for an example.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/shPlease include a notice when you submit a port (or an
upgrade) that reserves a new UID or GID in this range. This allows
us to keep the list of reserved IDs up to date.Do things rationallyThe Makefile should do things simply and
reasonably. If you can make it a couple of lines shorter or more
readable, then do so. Examples include using a make
.if construct instead of a shell
if construct, not redefining
do-extract if you can redefine
EXTRACT* instead, and using
GNU_CONFIGURE instead of
CONFIGURE_ARGS +=
--prefix=${PREFIX}.Respect CFLAGSThe port should respect the CFLAGS
variable. If it doesn't, please add NO_PACKAGE=ignores
cflags to the Makefile.Configuration filesIf your port requires some configuration files in
PREFIX/etc, do
not just install them and list them in
pkg/PLIST. That will cause
pkg_delete to delete files carefully edited by
the user and a new installation to wipe them out.Instead, install sample files with a suffix
(filename.sample
will work well) and print out a message pointing out that the
user has to copy and edit the file before the software can be made
to work.PortlintDo check your work with portlint
before you submit or commit it.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code. This
will only make your job that much easier for the next
release.MiscellaneaThe files pkg/DESCR,
pkg/COMMENT, and
pkg/PLIST should each be double-checked. If
you are reviewing a port and feel they can be worded better, do
so.Don't copy more copies of the GNU General Public License into
our system, please.Please be careful to note any legal issues! Don't let us
illegally distribute software!If you are stuck…Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample MakefileHere is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). This format is
designed so that the most important information is easy to
locate. We recommend that you use portlint to check the Makefile.
[the header...just to make it easier for us to identify the ports.]
# New ports collection makefile for: xdvi
[the version required header should updated when upgrading a port.]
# Version required: pl18 [things like "1.5alpha" are fine here too]
[this is the date when the first version of this Makefile was created.
Never change this when doing an update of the port.]
# Date created: 26 May 1995
[this is the person who did the original port to FreeBSD, in particular, the
person who wrote the first version of this Makefile. Remember, this should
not be changed when upgrading the port later.]
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
#
# $Id$
[ ^^^^ This will be automatically replaced with RCS ID string by CVS
when it is committed to our repository.]
#
[section to describe the port itself and the master site - DISTNAME
is always first, followed by PKGNAME (if necessary), CATEGORIES,
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be specified too.]
DISTNAME= xdvi
PKGNAME= xdvi-pl18
CATEGORIES= print
[do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros]
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz" form]
EXTRACT_SUFX= .tar.Z
[section for distributed patches -- can be empty]
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[maintainer; *mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug reports - this
person should be the porter or someone who can forward questions to the
original porter reasonably promptly. If you really do not want to have
your address here, set it to "ports@FreeBSD.ORG".]
MAINTAINER= asami@FreeBSD.ORG
[dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm
[this section is for other standard bsd.port.mk variables that do not
belong to any of the above]
[If it asks questions during configure, build, install...]
IS_INTERACTIVE= yes
[If it extracts to a directory other than ${DISTNAME}...]
WRKSRC= ${WRKDIR}/xdvi-new
[If the distributed patches were not made relative to ${WRKSRC}, you
may need to tweak this]
PATCH_DIST_STRIP= -p1
[If it requires a "configure" script generated by GNU autoconf to be run]
GNU_CONFIGURE= yes
[If it requires GNU make, not /usr/bin/make, to build...]
USE_GMAKE= yes
[If it is an X application and requires "xmkmf -a" to be run...]
USE_IMAKE= yes
[et cetera.]
[non-standard variables to be used in the rules below]
MY_FAVORITE_RESPONSE= "yeah, right"
[then the special rules, in the order they are called]
pre-fetch:
i go fetch something, yeah
post-patch:
i need to do something after patch, great
pre-install:
and then some more stuff before installing, wow
[and then the epilogue]
.include <bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like language-name-compiled.specifics-version.numbers.If your DISTNAME
doesn't look like that, set PKGNAME to something in that
format.FreeBSD strives to support the native language of its
users. The language- part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
ja for Japanese, ru for Russian, vi for Vietnamese,
zh for Chinese, ko for Korean and de for German.The name part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a port of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the capital letters are
important to the name (for example, with one-letter names
like R or V) you may use capital letters at your discretion.
There is a tradition of naming Perl 5 modules by prepending
p5- and converting the double-colon separator to a hyphen;
for example, the Data::Dumper module becomes
p5-Data-Dumper. If the software in question has numbers,
hyphens, or underscores in its name, you may include them as
well (like kinput2).If the port can be built with different hardcoded
defaults (usually part of the directory name in a
family of ports), the
-compiled.specifics part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string pl (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a DISTNAME into a suitable PKGNAME:Distribution NamePackage NameReasonmule-2.2.2.mule-2.2.2No changes requiredXFree86-3.1.2XFree86-3.1.2No changes requiredEmiClock-1.0.2emiclock-1.0.2No uppercase names for single programsgmod1.4gmod-1.4Need a hyphen before version numbersxmris.4.0.2xmris-4.0.2Need a hyphen before version numbersrdist-1.3alphardist-1.3aNo strings like alpha
allowedes-0.9-beta1es-0.9b1No strings like beta
allowedv3.3beta021.srctiff-3.3What the heck was that anyway?tvtwmtvtwm-pl11Version string always requiredpiewmpiewm-1.0Version string always requiredxvgr-2.10pl1xvgr-2.10.1pl allowed only when no
major/minor version numbersgawk-2.15.6ja-gawk-2.15.6Japanese language versionpsutils-1.13psutils-letter-1.13Papersize hardcoded at package build timepkfontspkfonts300-1.0Package for 300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to 1.0 (like the piewm example above). Otherwise, ask the
original author or use the date string (yy.mm.dd) as the
version.CategoriesAs you already know, ports are classified in several
categories. But for this to wor, it is important that porters and
users understand what each category and how we deicde what to put in
each category.Current list of categoriesFirst, this is the current list of port categories. Those
marked with an asterisk (*) are
virtual categories—those that do not
have a corresponding subdirectory in the ports tree.For non-virtual categories, you will find a one-line
description in the pkg/COMMENT file in that
subdirectory (e.g.,
archivers/pkg/COMMENT).CategoryDescription
+
+ afterstep*
+ Ports to support AfterStep window manager
+
+
archiversArchiving tools.astroAstronomical ports.audioSound support.benchmarksBenchmarking utilities.biologyBiology-related software.cadComputer aided design tools.chineseChinese language support.commsCommunication software. Mostly software to talk to
your serial port.convertersCharacter code converters.databasesDatabases.deskutilsThings that used to be on the desktop before
computers were invented.develDevelopment utilities. Do not put libraries here just
because they are libraries—unless they truly don't
belong to anywhere else, they shouldn't be in this
category.editorsGeneral editors. Specialized editors go in the
section for those tools (e.g., a mathematical-formula
editor will go in math).elispEmacs-lisp ports.emulatorsEmulators for other operating systems. Terminal
emulators do not belong
here—X-based ones should go to
x11 and text-based ones to either
comms or misc,
depending on the exact functionality.gamesGames.germanGerman language support.graphicsGraphics utilities.japaneseJapanese language support.kde*Ports that form the K Desktop Environment
(kde).koreanKorean language support.langProgramming languages.mailMail software.mathNumerical computation software and other utilities
for mathematics.mboneMBone applications.miscMiscellaneous utilities—basically things that
doesn't belong to anywhere else. This is the only category
that should not appear with any other non-virtual
category. If you have misc with
something else in your CATEGORIES line,
that means you can safely delete misc
and just put the port in that other subdirectory!netMiscellaneous networking software.newsUSENET news software.offix*Ports from the OffiX suite.
- perl5*
- Ports that require perl version 5 to run.
+ palm
+ Software support for the 3Com Palm(tm) series.
-
+
- pilot*
- Software to use with the 3Com PalmPilot.
+ perl5*
+ Ports that require perl version 5 to run.
- plan9
+ plan9*Various programs from Plan9.printPrinting software. Desktop publishing tools
(previewers, etc.) belong here too.python*Software written in python.russianRussian language support.securitySecurity utilities.shellsCommand line shells.sysutilsSystem utilities.tcl75*Ports that use tcl version 7.5 to run.tcl76*Ports that use tcl version 7.6 to run.tcl80*Ports that use tcl version 8.0 to run.tcl81*Ports that use tcl version 8.1 to run.textprocText processing utilities. It does not include
desktop publishing tools, which go to print/.tk41*Ports that use tk version 4.1 to run.tk42*Ports that use tk version 4.2 to run.tk80*Ports that use tk version 8.0 to run.tk81*Ports that use tk version 8.1 to run.vietnameseVietnamese language support.
+
+ windowmaker*
+ Ports to support the WindowMaker window
+ manager
+
+
wwwSoftware related to the World Wide Web. HTML language
support belong here too.x11The X window system and friends. This category is
only for software that directly support the window system.
Do not put regular X applications here. If your port is
an X application, define USE_XLIB
(implied by USE_IMAKE) and put it in
appropriate categories. Also, many of them go into other
x11-* categories (see below).x11-clocksX11 clocks.x11-fmX11 file managers.x11-fontsX11 fonts and font utilities.x11-toolkitsX11 toolkits.x11-wmX11 window managers.Choosing the right categoryAs many of the categories overlap, you often have to choose
which of the categories should be the primary category of your
port. There are several rules that govern this usse. Here is the
list of priorities, in decreasing order of precedence.Language specific categories alwasys come first. For
example, if your port installs Japanese X11 fonts, then your
CATEGORIES line would read
japanese x11.Specific categories win over less-specific ones. For
instance, an HTML editor should be listed as www
editors, not the other way around. Also, you don't
need to list net when the port belongs to
either of mail, mbone,
news, security, or
www.x11 is used as a secondary category
only when the primary category is a natural language. In
particular, you should not put x11 in the
category line for X applications.If your port truly does not belong anywhere else, put it
in misc.If you are not sure about the category, please put a comment
to that effect in your send-pr submission so we
can discuss it before import it. (If you are a committer, send a
note &a.ports; so we can discuss it first—too often new
ports are imported to a wrong category only to be moved right
away.)Changes to this document and the ports systemIf you maintain a lot of ports, you should consider following
the &a.ports;. Important changes to
the way ports work will be announced there. You can always
find more detailed information on the latest changes by
looking at
the bsd.port.mk CVS log.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)
diff --git a/en/handbook/security/chapter.sgml b/en/handbook/security/chapter.sgml
index 00fcb1dc43..ccc28daebc 100644
--- a/en/handbook/security/chapter.sgml
+++ b/en/handbook/security/chapter.sgml
@@ -1,1710 +1,1711 @@
SecurityDES, MD5, and CryptContributed by &a.wollman;24 September
1995.In order to protect the security of passwords on UN*X systems
from being easily exposed, passwords have traditionally been
scrambled in some way. Starting with Bell Labs' Seventh Edition
Unix, passwords were encrypted using what the security people call a
“one-way hash function”. That is to say, the password is
transformed in such a way that the original password cannot be
regained except by brute-force searching the space of possible
passwords. Unfortunately, the only secure method that was available
to the AT&T researchers at the time was based on DES, the Data
Encryption Standard. This causes only minimal difficulty for
commercial vendors, but is a serious problem for an operating system
like FreeBSD where all the source code is freely available, because
national governments in many places like to place restrictions on
cross-border transport of DES and other encryption software.So, the FreeBSD team was faced with a dilemma: how could we
provide compatibility with all those UNIX systems out there while
still not running afoul of the law? We decided to take a dual-track
approach: we would make distributions which contained only a
non-regulated password scrambler, and then provide as a separate
add-on library the DES-based password hash. The password-scrambling
function was moved out of the C library to a separate library,
called libcrypt because the name of
the C function to implement it is crypt. In FreeBSD 1.x and some pre-release
2.0 snapshots, the non-regulated scrambler uses an insecure function
written by Nate Williams; in subsequent releases this was replaced
by a mechanism using the RSA Data Security, Inc., MD5 one-way hash
function. Because neither of these functions involve encryption,
they are believed to be exportable from the US and importable into
many other countries.Meanwhile, work was also underway on the DES-based password hash
function. First, a version of the crypt function which was written outside the
US was imported, thus synchronizing the US and non-US code. Then,
the library was modified and split into two; the DES libcrypt contains only the code involved in
performing the one-way password hash, and a separate libcipher was created with the entry points
to actually perform encryption. The code was partitioned in this
way to make it easier to get an export license for the compiled
library.Recognizing your crypt
mechanismIt is fairly easy to recognize whether a particular password
string was created using the DES- or MD5-based hash function. MD5
password strings always begin with the characters $1$. DES password strings do not
have any particular identifying characteristics, but they are
shorter than MD5 passwords, and are coded in a 64-character
alphabet which does not include the $ character, so a relatively short
string which doesn't begin with a dollar sign is very likely a DES
password.Determining which library is being used on your system is
fairly easy for most programs, except for those like init which are statically linked. (For
those programs, the only way is to try them on a known password
and see if it works.) Programs which use crypt are linked against libcrypt, which for each type of library is
a symbolic link to the appropriate implementation. For example,
on a system using the DES versions:&prompt.user; cd /usr/lib
&prompt.user; ls -l /usr/lib/libcrypt*
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.aOn a system using the MD5-based libraries, the same links will
be present, but the target will be libscrypt
rather than libdescrypt.S/KeyContributed by &a.wollman;25 September
1995.S/Key is a one-time password scheme based on a one-way hash
function (in our version, this is MD4 for compatibility; other
versions have used MD5 and DES-MAC). S/Key has been a standard part
of all FreeBSD distributions since version 1.1.5, and is also
implemented on a large and growing number of other systems. S/Key
is a registered trademark of Bell Communications Research,
Inc.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual UNIX-style
or Kerberos password; we will call this a “UNIX password”. The
second sort is the one-time password which is generated by the S/Key
key program and accepted by the
keyinit program and the login
prompt; we will call this a “one-time password”. The final sort
of password is the secret password which you give to the key program (and sometimes the keyinit program) which it uses to generate
one-time passwords; we will call it a “secret password” or just
unqualified “password”.The secret password does not necessarily have anything to do
with your UNIX password (while they can be the same, this is not
recommended). While UNIX passwords are limited to eight characters
in length, your S/Key secret password can be as long as you like; I
use seven-word phrases. In general, the S/Key system operates
completely independently of the UNIX password system.There are in addition two other sorts of data involved in the
S/Key system; one is called the “seed” or (confusingly) “key”,
and consists of two letters and five digits, and the other is the
“iteration count” and is a number between 100 and 1. S/Key
constructs a one-time password from these components by
concatenating the seed and the secret password, then applying a
one-way hash (the RSA Data Security, Inc., MD4 secure hash function)
iteration-count times, and turning the result into six short English
words. The login and su programs keep track of the last one-time
password used, and the user is authenticated if the hash of the
user-provided password is equal to the previous password. Because a
one-way hash function is used, it is not possible to generate future
one-time passwords having overheard one which was successfully used;
the iteration count is decremented after each successful login to
keep the user and login program in sync. (When you get the
iteration count down to 1, it is time to reinitialize S/Key.)There are four programs involved in the S/Key system which we
will discuss below. The key program
accepts an iteration count, a seed, and a secret password, and
generates a one-time password. The keyinit program is used to initialized S/Key,
and to change passwords, iteration counts, or seeds; it takes either
a secret password, or an iteration count, seed, and one-time
password. The keyinfo program
examines the /etc/skeykeys file and prints out
the invoking user's current iteration count and seed. Finally, the
login and su programs contain the necessary logic to
accept S/Key one-time passwords for authentication. The login program is also capable of disallowing
the use of UNIX passwords on connections coming from specified
addresses.There are four different sorts of operations we will cover. The
first is using the keyinit program
over a secure connection to set up S/Key for the first time, or to
change your password or seed. The second operation is using the
keyinit program over an insecure
connection, in conjunction with the key program over a secure connection, to do
the same. The third is using the key program to log in over an insecure
connection. The fourth is using the key program to generate a number of keys
which can be written down or printed out to carry with you when
going to some location without secure connections to anywhere (like
at a conference).Secure connection initializationTo initialize S/Key, change your password, or change your seed
while logged in over a secure connection (e.g., on the console of
a machine), use the keyinit
command without any parameters while logged in as yourself:&prompt.user; keyinit
Updating wollman: ) these will not appear if you
Old key: ha73895 ) have not used S/Key before
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password: ) I typed my pass phrase here
Again secret password: ) I typed it again ID
wollman s/key is 99 ha73896 ) discussed below SAG
HAS FONT GOUT FATE BOOM )There is a lot of information here. At theEnter secret
password: prompt, you should enter some password or phrase (I use
phrases of minimum seven words) which will be needed to generate
login keys. The line starting `ID' gives the parameters of your
particular S/Key instance: your login name, the iteration count,
and seed. When logging in with S/Key, the system will remember
these parameters and present them back to you so you do not have
to remember them. The last line gives the particular one-time
password which corresponds to those parameters and your secret
password; if you were to re-login immediately, this one-time
password is the one you would use.Insecure connection initializationTo initialize S/Key or change your password or seed over an
insecure connection, you will need to already have a secure
connection to some place where you can run the key program; this might be in the form of a
desk accessory on a Macintosh, or a shell prompt on a machine you
trust (we will show the latter). You will also need to make up an
iteration count (100 is probably a good value), and you may make
up your own seed or use a randomly-generated one. Over on the
insecure connection (to the machine you are initializing), use the
keyinit -s command:&prompt.user; keyinit -s
Updating wollman: Old key: kh94741
Reminder you need the 6 English words from the skey command.
Enter sequence count from 1 to 9999:100 ) I typed this
Enter new key [default kh94742]:
s/key 100 kh94742To accept the default seed (which the keyinit program
confusingly calls a key), press return. Then move over to your
secure connection or S/Key desk accessory, and give it the same
parameters:&prompt.user; key 100 kh94742
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
HULL NAY YANG TREE TOUT VETONow switch back over to the insecure connection, and copy the
one-time password generated by key
over to the keyinit
program:s/key access password:HULL NAY YANG TREE TOUT VETO
ID wollman s/key is 100 kh94742
HULL NAY YANG TREE TOUT VETOThe rest of the description from the previous section applies
here as well.Diversion: a login promptBefore explaining how to generate one-time passwords, we
should go over an S/Key login prompt:&prompt.user; telnet himalia
Trying 18.26.0.186...
Connected to himalia.lcs.mit.edu.
Escape character is '^]'.
s/key 92 hi52030
Password:Note that, before prompting for a password, the login program
prints out the iteration number and seed which you will need in
order to generate the appropriate key. You will also find a
useful feature (not shown here): if you press return at the
password prompt, the login program will turn echo on, so you can
see what you are typing. This can be extremely useful if you are
attempting to type in an S/Key by hand, such as from a
printout.If this machine were configured to disallow UNIX passwords
over a connection from my machine, the prompt would have also
included the annotation (s/key
required), indicating that only S/Key one-time
passwords will be accepted.Generating a single one-time passwordNow, to generate the one-time password needed to answer this
login prompt, we use a trusted machine and the key program. (There are versions of the
key program from DOS and Windows
machines, and there is an S/Key desk accessory for Macintosh
computers as well.) The command-line key program takes as its parameters the
iteration count and seed; you can cut-and-paste right from the
login prompt starting at key to
the end of the line. Thus:&prompt.user; key 92 hi52030 ) pasted from previous section
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
ADEN BED WOLF HAW HOT STUNAnd in the other window:s/key 92 hi52030 ) from previous section
Password:
(turning echo on)
Password:ADEN BED WOLF HAW HOT STUN
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
[etc.]This is the easiest mechanism if you have
a trusted machine. There is a Java S/Key key applet, The Java OTP
Calculator, that you can download and run locally on any
Java supporting brower.Generating multiple one-time passwordsSometimes we have to go places where no trusted machines or
connections are available. In this case, it is possible to use
the key command to generate a
number of one-time passwords in the same command; these can then
be printed out. For example:&prompt.user; key -n 25 57 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
33: WALT THY MALI DARN NIT HEAD
34: ASK RICE BEAU GINA DOUR STAG
…
56: AMOS BOWL LUG FAT CAIN INCH
57: GROW HAYS TUN DISH CAR BALMThe requests twenty-five keys in
sequence; the indicates the
ending iteration number; and the rest is as
before. Note that these are printed out in
reverse order of eventual use. If you are
really paranoid, you might want to write the results down by hand;
otherwise you can cut-and-paste into lpr. Note that each line shows both the
iteration count and the one-time password; you may still find it
handy to scratch off passwords as you use them.Restricting use of UNIX passwordsThe configuration file /etc/skey.access
can be used to configure restrictions on the use of UNIX passwords
based on the host name, user name, terminal port, or IP address of
a login session. The complete format of the file is documented in
the skey.access5 manual page; there are
also some security cautions there which should be read before
depending on this file for security.If there is no /etc/skey.access file
(which is the default state as FreeBSD is shipped), then all users
will be allowed to use UNIX passwords. If the file exists,
however, then all users will be required to use S/Key unless
explicitly permitted to do otherwise by configuration statements
in the skey.access file. In all cases, UNIX
passwords are permitted on the console.Here is a sample configuration file which illustrates the
three most common sorts of configuration statements:
permit internet 18.26.0.0 255.255.0.0
permit user jrl
permit port ttyd0The first line (permit
internet) allows users whose IP source address
(which is vulnerable to spoofing) matches the specified value and
mask, to use UNIX passwords. This should not be considered a
security mechanism, but rather, a means to remind authorized users
that they are using an insecure network and need to use S/Key for
authentication.The second line (permit user)
allows the specified user to use UNIX passwords at any time.
Generally speaking, this should only be used for people who are
either unable to use the key
program, like those with dumb terminals, or those who are
uneducable.The third line (permit port)
allows all users logging in on the specified terminal line to use
UNIX passwords; this would be used for dial-ups.KerberosContributed by &a.markm; (based on contribution by
&a.md;).Kerberos is a network add-on system/protocol that allows users
to authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and
more controllable.The following instructions can be used as a guide on how to set
up Kerberos as distributed for FreeBSD. However, you should refer to
the relevant manual pages for a complete description.In FreeBSD, the Kerberos is not that from the original
4.4BSD-Lite, distribution, but eBones, which had been previously
ported to FreeBSD 1.1.5.1, and was sourced from outside the
USA/Canada, and is thus available to system owners outside those
countries.For those needing to get a legal foreign distribution of this
software, please do not get it from a USA or
Canada site. You will get that site in big
trouble! A legal copy of this is available from
ftp.internat.freebsd.org, which is in
South Africa and an official FreeBSD mirror site.Creating the initial databaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should
change to the directory /etc/kerberosIV and
check that only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as
principal.* or master_key)
exist, then use the kdb_destroy command to
destroy the old Kerberos database, of if Kerberos is not running,
simply delete the extra files.You should now edit the krb.conf and
krb.realms files to define your Kerberos
realm. In this case the realm will be
GRONDAR.ZA and the server is
grunt.grondar.za. We edit or create the
krb.conf file:&prompt.root; cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They
are here as an example of how a machine may be made aware of
multiple realms. You may wish to not include them for
simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line
is a realm, and the second is a host in that realm that is acting
as a “key distribution centre”. The words admin server
following a hosts name means that host also provides an
administrative database server. For further explanation of these
terms, please consult the Kerberos man pages.Now we have to add grunt.grondar.za to
the GRONDAR.ZA realm and also add an entry to
put all hosts in the .grondar.za domain in
the GRONDAR.ZA realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here
as an example of how a machine may be made aware of multiple
realms. You may wish to remove them to simplify things.The first line puts the specific
system into the named realm. The rest of the lines show how to
default systems of a particular subdomain to a named realm.Now we are ready to create the database. This only needs to
run on the Kerberos server (or Key Distribution Centre). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:GRONDAR.ZA
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local
machine can pick it up. Use the kstash command to do this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making it all runTwo principals need to be added to the database for each system that will be secured with
Kerberos. Their names are kpasswd
and rcmd These two principals are
made for each system, with the instance being the name of the
individual system.These daemons, kpasswd and
rcmd allow other systems to change
Kerberos passwords and run commands like rcp, rlogin
and rsh.Now let's add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the server fileWe now have to extract all the instances which define the
services on each machine. For this we use the
ext_srvtab command. This will create a file which
must be copied or moved by secure
means to each Kerberos client's /etc/kerberosIV
directory. This file must be present on each server and client,
and is crucial to the operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must
be renamed to srvtab so that all the
server can pick it up. Use the mv
command to move it into place on the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not
deemed safe, then copy the client-new-srvtab to removable media
and transport it by secure physical means. Be sure to rename it to
srvtab in the client's
/etc/kerberosIV directory, and make sure it
is mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the databaseWe now have to add some user entries into the database. First
let's create an entry for the user jane. Use
the kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting it all outFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then
this will happen automatically when you reboot. This is only
necessary on the Kerberos server. Kerberos clients will
automagically get what they need from the
/etc/kerberosIV directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit
command to get a ticket for the id jane that we created above:&prompt.user; kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZANow try changing the password using passwd to check if the kpasswd daemon can
get authorization to the Kerberos database:&prompt.user; passwd
realm GRONDAR.ZA
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su privilegesKerberos allows us to give each
user who needs root privileges their own separatesupassword. We could now add an id which is
authorized to su to root. This is controlled by having an
instance of root associated with a
principal. Using kdb_edit we can create the
entry jane.root in the Kerberos
database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's
.klogin file:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZANow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZAUsing other commandsIn an earlier example, we created a principal called
jane with an instance root. This was based on a user with the same
name as the principal, and this is a Kerberos default; that a
<principal>.<instance> of the
form <username>.root will allow that
<username> to su to root if the necessary entries are in
the .klogin file in root's home directory:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZALikewise, if a user has in their own home directory lines of
the form:&prompt.user; cat ~/.klogin
jane@GRONDAR.ZA
jack@GRONDAR.ZAThis allows anyone in the GRONDAR.ZA
realm who has authenticated themselves to
jane or jack (via
kinit, see above) access to
rlogin to
jane's account or files on this system
(grunt) via rlogin, rsh or
rcp.For example, Jane now logs into another system, using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.grondar.za)
Password:
%prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine (Jane
having set up the .klogin file as above, and
the person in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.grondar.za)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995FirewallsContributed by &a.gpalmer; and
&a.alex;.Firewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on
private networks to provide enhanced security. This section will
hopefully explain what firewalls are, how to use them, and how to
use the facilities provided in the FreeBSD kernel to implement
them.People often think that having a firewall between your
companies internal network and the “Big Bad Internet”
will solve all your security problems.It may help, but a poorly setup firewall system is more of a
security risk than not having one at all. A firewall can only add
another layer of security to your systems, but they will not be
able to stop a really determined cracker from penetrating your
internal network. If you let internal security lapse because you
believe your firewall to be impenetrable, you have just made the
crackers job that bit easier.What is a firewall?There are currently two distinct types of firewalls in common
use on the Internet today. The first type is more properly called
a packet filtering router, where the
kernel on a multi-homed machine chooses whether to forward or
block packets based on a set of rules. The second type, known as
proxy servers, rely on daemons to
provide authentication and to forward packets, possibly on a
multi-homed machine which has kernel packet forwarding
disabled.Sometimes sites combine the two types of firewalls, so that
only a certain machine (known as a bastion
host) is allowed to send packets through a packet
filtering router onto an internal network. Proxy services are run
on the bastion host, which are generally more secure than normal
authentication mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this section
will concentrate on. Proxy servers can be built on FreeBSD from
third party software, but there is such a variety of proxy servers
available that it would be impossible to cover them in this
document.Packet filtering routersA router is a machine which forwards packets between two or
more networks. A packet filtering router has an extra piece of
code in its kernel, which compares each packet to a list of
rules before deciding if it should be forwarded or not. Most
modern IP routing software has packet filtering code in it,
which defaults to forwarding all packets. To enable the filters,
you need to define a set of rules for the filtering code, so
that it can decide if the packet should be allowed to pass or
not.To decide if a packet should be passed on or not, the code
looks through its set of rules for a rule which matches the
contents of this packets headers. Once a match is found, the
rule action is obeyed. The rule action could be to drop the
packet, to forward the packet, or even to send an ICMP message
back to the originator. Only the first match counts, as the
rules are searched in order. Hence, the list of rules can be
referred to as a “rule chain”.The packet matching criteria varies depending on the
software used, but typically you can specify rules which depend
on the source IP address of the packet, the destination IP
address, the source port number, the destination port number
(for protocols which support ports), or even the packet type
(UDP, TCP, ICMP, etc).Proxy serversProxy servers are machines which have had the normal system
daemons (telnetd, ftpd, etc) replaced with special servers.
These servers are called proxy
servers as they normally only allow onward
connections to be made. This enables you to run (for example) a
proxy telnet server on your firewall host, and people can telnet
in to your firewall from the outside, go through some
authentication mechanism, and then gain access to the internal
network (alternatively, proxy servers can be used for signals
coming from the internal network and heading out).Proxy servers are normally more secure than normal servers,
and often have a wider variety of authentication mechanisms
available, including “one-shot” password systems so that even
if someone manages to discover what password you used, they will
not be able to use it to gain access to your systems as the
password instantly expires. As they do not actually give users
access to the host machine, it becomes a lot more difficult for
someone to install backdoors around your security system.Proxy servers often have ways of restricting access further,
so that only certain hosts can gain access to the servers, and
often they can be set up so that you can limit which users can
talk to which destination machine. Again, what facilities are
available depends largely on what proxy software you
choose.What does IPFW allow me to do?IPFW, the software supplied with FreeBSD,
is a packet filtering and accounting system which resides in the
kernel, and has a user-land control utility,
ipfw8. Together, they allow you to define and
query the rules currently used by the kernel in its routing
decisions.There are two related parts to IPFW. The
firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of
your router, based on similar rules to the firewall section. This
allows you to see (for example) how much traffic your router is
getting from a certain machine, or how much WWW (World Wide Web)
traffic it is forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDAs the main part of the IPFW system lives
in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want,
and recompile your kernel. See
reconfiguring the kernel for
more details on how to recompile your kernel.There are currently three kernel configuration options
relevant to IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
syslogd8. Without this option, even
if you specify that packets should be logged in the filter
rules, nothing will happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
syslogd8 on a per entry basis. You
may wish to use this option in hostile environments in
which you want to log firewall activity, but do not want
to be open to a denial of service attack via syslog
flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To
resume logging, you will need to reset the associated
counter using the ipfw8
utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWThe configuration of the IPFW software is
done through the ipfw8 utility. The syntax
for this command looks quite complicated, but it is relatively
simple once you understand its structure.There are currently four different command categories used by
the utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how
packets are accepted, rejected, and logged. Listing is used to
examine the contents of your rule set (otherwise known as the
chain) and packet counters (accounting). Flushing is used to
remove all entries from the chain. Clearing is used to zero out
one or more accounting entries.Altering the IPFW rulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in
output.The command given can be shortened to
the shortest unique form. The valid
commands are:addAdd an entry to the firewall/accounting rule
listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used separate
firewall and accounting entries. The present version provides
packet accounting with each firewall entry.If an index value is supplied,
it used to place the entry at a specific point in the chain.
Otherwise, the entry is placed at the end of the chain at an
index 100 greater than the last chain entry (this does not
include the default policy, rule 65535, deny).The log option causes matching
rules to be output to the system console if the kernel was
compiled with IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port
unreachable (as appropriate) packet to the
source.allowPass the packet on as normal. (aliases:
pass and accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the
packet based on this rule. The search continues with
the next chain entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/markportvia interfaceYou can only specify port in
conjunction with protocols which support
ports (UDP and TCP).The is optional and may
specify the IP address or domain name of a local IP interface,
or an interface name (e.g. ed0) to
match only packets coming through this interface. Interface unit
numbers can be specified with an optional wildcard. For example,
ppp* would match all kernel PPP
interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP
address. is a decimal
number representing how many bits in the address mask should be
set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any
address in a class C subnet (in this case, 192.216.222) to be
matched. is an IP
address which will be logically AND'ed with the address given.
The keyword any may be used to
specify “any IP address”.The port numbers to be blocked are specified as:
port,port,port…to specify either a single port or a list of
ports, or
port-port to specify a range of ports. You may also
combine a single range with a list, but the range must always be
specified first.The options available are:fragMatches if the packet is not the first fragment of
the datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma
separated list of options specified in
spec. The supported list of IP
options are: ssrr (strict
source route), lsrr (loose
source route), rr (record
packet route), and ts
(timestamp). The absence of a particular option may be
denoted with a leading !.establishedMatches if the packet is part of an already
established TCP connection (i.e. it has the RST or ACK
bits set). You can optimize the performance of the
firewall by placing established
rules early in the chain.setupMatches if the packet is an attempt to establish a
TCP connection (the SYN bit set is set but the ACK bit
is not).tcpflags flagsMatches if the TCP header contains the comma
separated list of flags. The
supported flags are fin,
syn, rst,
psh, ack, and
urg. The absence of a particular
flag may be indicated by a leading !.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types
separated by commas. Commonly used ICMP types are:
0 echo reply (ping reply),
+ 3 destination unreachable,
5 redirect, 8 echo request (ping request), and
11 time exceeded (used to
indicate TTL expiration as with
traceroute8).Listing the IPFW rulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is
the only way to see accounting counters.-tDisplay the last match times for each chain entry.
The time listing is incompatible with the input syntax
used by the ipfw8 utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW rulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny
policy will leave your system cut off from the network until
allow entries are added to the chain.Clearing the IPFW packet countersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example commands for ipfwThis command will deny all packets from the host
evil.crackers.org to the telnet port of the
host nice.people.org by being forwarded by
the router:&prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the
entire crackers.org network (a class C) to the
nice.people.org machine (any port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry
was matched with:&prompt.root; ipfw -at lBuilding a packet filtering firewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and I cannot tell
you how to build a firewall to meet your particular
requirements.When initially setting up your firewall, unless you have a
test bench setup where you can configure your firewall host in a
controlled environment, I strongly recommend you use the logging
version of the commands and enable logging in the kernel. This
will allow you to quickly identify problem areas and cure them
without too much disruption. Even after the initial setup phase is
complete, I recommend using the logging for of `deny' as it allows
tracing of possible attacks and also modification of the firewall
rules if your requirements alter.If you use the logging versions of the accept command, it can generate
large amounts of log data as one log line
will be generated for every packet that passes through the
firewall, so large ftp/http transfers, etc, will really slow the
system down. It also increases the latencies on those packets as
it requires more work to be done by the kernel before the packet
can be passed on. syslogd with also start using up a lot more
processor time as it logs all the extra data to disk, and it
could quite easily fill the partition
/var/log is located on.As currently supplied, FreeBSD does not have the ability to
load firewall rules at boot time. My suggestion is to put a call
to a shell script in the /etc/netstart
script. Put the call early enough in the netstart file so that the
firewall is configured before any of the IP interfaces are
configured. This means that there is no window during which time
your network is open.The actual script used to load the rules is entirely up to
you. There is currently no support in the ipfw utility for loading multiple rules in
the one command. The system I use is to use the command:&prompt.root; ipfw listto write a list of the current rules out to a file, and then
use a text editor to prepend ipfw
before all the lines. This will allow the script to
be fed into /bin/sh and reload the rules into the kernel. Perhaps
not the most efficient way, but it works.The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much
access to the outside world you want to allow from the inside.
Some general rules are:Block all incoming access to ports below 1024 for TCP.
This is where most of the security sensitive services are,
like finger, SMTP (mail) and telnet.Block all incoming UDP
traffic. There are very few useful services that travel over
UDP, and what useful traffic there is is normally a security
threat (e.g. Suns RPC and NFS protocols). This has its
disadvantages also, since UDP is a connectionless protocol,
denying incoming UDP traffic also blocks the replies to
outgoing UDP traffic. This can cause a problem for people
(on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
packets coming from ports 191 and 1525 to any internal UDP
port through the firewall. ntp is another service you may
consider allowing through, which comes from port 123.Block traffic to port 6000 from the outside. Port 6000
is the port used for access to X11 servers, and can be a
security threat (especially if people are in the habit of
doing xhost + on their
workstations). X11 can actually use a range of ports
starting at 6000, the upper limit being how many X displays
you can run on the machine. The upper limit as defined by
RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL
servers, etc). It is probably a good idea to block those as
well, as they normally fall outside the 1-1024 range
specified above.Another checklist for firewall configuration is available from
CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filteringAs I said above, these are only
guidelines. You will have to decide what
filter rules you want to use on your firewall yourself. I cannot
accept ANY responsibility if someone breaks into your network,
even if you follow the advice given above.
diff --git a/en/handbook/staff/chapter.sgml b/en/handbook/staff/chapter.sgml
index b34fa0411c..85ff0bc7b4 100644
--- a/en/handbook/staff/chapter.sgml
+++ b/en/handbook/staff/chapter.sgml
@@ -1,794 +1,838 @@
FreeBSD Project StaffThe FreeBSD Project is managed and operated by the following
groups of people:The FreeBSD Core TeamThe FreeBSD core team constitutes the project's “Board of
Directors”, responsible for deciding the project's overall goals
and direction as well as managing specific
areas of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.bde;&a.gibbs;&a.dg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.guido;&a.sos;&a.peter;&a.wollman;&a.joerg;The FreeBSD DevelopersThese are the people who have commit privileges and do the
engineering work on the FreeBSD source tree. All core team members
are also developers.&a.ugen;&a.mbarkah;&a.stb;&a.pb;&a.abial;&a.jb;&a.torstenb;&a.dburr;&a.charnier;&a.luoqi;&a.ejc;&a.kjc;&a.gclarkii;&a.archie&a.cracauer;&a.adam;&a.dillon;&a.dufault;&a.uhclem;&a.tegge;&a.eivind;&a.julian;&a.rse;&a.se;&a.sef;&a.fenner;&a.jfieber;&a.jfitz;&a.scrappy;&a.lars;
+
+ &.dirk;
+
+
&a.billf;
-
+
+
+ &a.gallatin;
+
+
&a.tg;&a.brandon;&a.graichen;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.thepish;&a.jhay;&a.helbig;&a.ghelmer;&a.erich;&a.nhibma;&a.flathill;
-
+
+
+ &a.foxfair;
+
+
&a.hosokawa;&a.hsu;&a.mph;&a.itojun;&a.mjacob;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.motoyuki;&a.jkoshy;&a.kuriyama;&a.grog;&a.jlemon;&a.truckman;&a.imp;&a.smace;&a.mckay;&a.mckusick;&a.ken;
-
+
+
+ &a.hm;
+
+
&a.tedm;&a.amurai;&a.markm;&a.max;&a.alex;
+
+ &a.newton;
+
+
&a.rnordier;&a.davidn;&a.obrien;&a.danny;&a.ljo;&a.fsmp;&a.smpatel;&a.wpaul;&a.jmacd;&a.wes;&a.steve;&a.mpp;&a.dfr;&a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.dima;&a.sada;&a.wosch;&a.ats;&a.jseger;
-
+
+
+ &a.simokawa;
+
+
&a.vanilla;&a.msmith;&a.des;&a.brian;
-
+
+
+ &a.mks;
+
+
&a.stark;&a.karl;&a.dt;&a.cwt;&a.pst;&a.hoek;&a.nectar;&a.swallace;&a.dwhite;&a.nate;&a.yokota;&a.jmz;&a.archie;The FreeBSD Documentation ProjectThe FreeBSD
Documentation Project is responsible for a number of
different services, each service being run by an individual and his
deputies (if any):Documentation Project Manager&a.nik;Webmaster&a.wosch;Handbook & FAQ Editor&a.faq;News Editor&a.nsj;Deputy: &a.john;FreeBSD Really-Quick NewsLetter EditorChris Coleman chrisc@vmunix.com
- Gallery and Commercial Editor
+ Gallery Editor&a.nsj;Deputy: &a.cawimm;
-
+
+
+ Commercial Editor
+
+
+ &a.mbarkah;
+
+
+
+
+ Web Changes Editor
+
+
+ &a.mbarkah;
+
+
+
Style Police & Art Director&a.opsys;Database Engineer&a.mayo;CGI Engineer&a.stb;Bottle Washing&a.nsj;LinuxDoc to DocBook conversion&a.nik;Who Is Responsible for WhatPrincipal Architect&a.dg;Documentation Project Manager&a.nik;Internationalization&a.ache;Networking&a.wollman;Postmaster&a.jmb;Release Coordinator&a.jkh;Public Relations & Corporate
Liaison&a.jkh;Security Officer&a.guido;>Source Repository ManagersPrincipal: &a.peter;Assistant: &a.jdp;International (Crypto): &a.markm;Ports Manager&a.asami;XFree86 Project, Inc. Liaison&a.rich;Usenet Support&a.joerg;GNATS Administrator&a.steve;Webmaster&a.wosch;
diff --git a/en_US.ISO8859-1/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml
index 2dffa913a2..bd3723e510 100644
--- a/en_US.ISO8859-1/articles/contributing/article.sgml
+++ b/en_US.ISO8859-1/articles/contributing/article.sgml
@@ -1,2895 +1,2954 @@
Contributing to FreeBSDContributed by &a.jkh;.So you want to contribute something to FreeBSD? That is great! We
can always use the help, and FreeBSD is one of those systems that
relies on the contributions of its user base in
order to survive. Your contributions are not only appreciated, they
are vital to FreeBSD's continued growth!Contrary to what some people might also have you believe, you do
not need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help
the project!Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product?
Please let us know! We may be able to work cooperatively on some
aspect of it. The free software world is challenging a lot of
existing assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at least give
it a second look.What Is NeededThe following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user
requests we have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If you are
interested in working on one of the tasks you see here, send mail to
the coordinator listed by clicking on their names. If no
coordinator has been appointed, maybe you would like to
volunteer?High priority tasksThe following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:3-stage boot issues. Overall coordination:
&a.hackers;Move userconfig (-c) into 3rd stage boot.Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.Filesystem problems. Overall coordination: &a.fs;Fix the MSDOS file system.Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;Fix the union file system. Coordinator:
&a.dg;Implement kernel and user vm86 support. Coordinator:
&a.jlemon;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;Kernel issues. Overall coordination: &a.hackers;Complete the eisaconf conversion of all existing
drivers.Change all interrupt routines to take a (void *)
instead of using unit numbers.Merge EISA/PCI/ISA interrupt registration
code.Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).Medium priority tasksThe following tasks need to be done, but not with any
particular urgency:Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth Jones ajones@ctron.comMCA support? This should be finalized one way or the
other.Full LKM based driver support/Configuration Manager.Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;Documentation!Reliable operation of the pcic driver (needs
testing).Recognizer and handler for
sio.c (mostly done).Recognizer and handler for
ed.c (mostly done).Recognizer and handler for
ep.c (mostly done).User-mode recognizer and handler (partially
done).Advanced Power Management. Coordinators: &a.msmith; and
&a.phk;APM sub-driver (mostly done).IDE/ATA disk sub-driver (partially done).syscons/pcvt sub-driver.Integration with the PCMCIA/PCCARD drivers
(suspend/resume).Low priority tasksThe following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them
done anytime soon:The first 20 items are from Terry Lambert
terry@lambert.orgAbility to make BIOS calls from protected mode using V86
mode on the processor and return the results via a mapped
interrupt IPC mechanism to the protected mode caller.Drivers built into the kernel that use the BIOS call
mechanism to allow them to be independent of the actual
underlying hardware the same way that DOS is independent of
the underlying hardware. This includes NetWork and ASPI
drivers loaded in DOS prior to BSD being loaded by a
DOS-based loader program, which means potential polling,
which means DOS-not-busy interrupt generation for V86
machines by the protected mode kernel.An image format that allows tagging of such drivers data
and text areas in the default kernel executable so that that
portion of the kernel address space may be recovered at a
later time, after hardware specific protected mode drivers
have been loaded and activated. This includes separation of
BIOS based drivers from each other, since it is better to
run with a BIOS based driver in all cases than to not run at
all.Abstraction of the bus interface mechanism. Currently,
PCMCIA, EISA, and PCI busses are assumed to be bridged from
ISA. This is not something which should be assumed.A configuration manager that knows about PNP events,
including power management events, insertion, extraction,
and bus (PNP ISA and PCMCIA bridging chips) vs. card level
event management.A topological sort mechanism for assigning reassignable
addresses that do not collide with other reassignable and
non-reassignable device space resource usage by fixed
devices.A registration based mechanism for hardware services
registration. Specifically, a device centric registration
mechanism for timer and sound and other system critical
service providers. Consider Timer2 and Timer0 and speaker
services as one example of a single monolithic service
provider.A kernel exported symbol space in the kernel data space
accessible by an LKM loader mechanism that does relocation
and symbol space manipulation. The intent of this interface
is to support the ability to demand load and unload kernel
modules.NetWare Server (protected mode ODI driver) loader and
subservices to allow the use of ODI card drivers supplied
with network cards. The same thing for NDIS drivers and
NetWare SCSI drivers.An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.Splitting of the console driver into abstraction layers,
both to make it easier to port and to kill the X and
ThinkPad and PS/2 mouse and LED and console switching and
bouncing NumLock problems once and for all.Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.Streams to allow the use of commercial streams drivers.Kernel multithreading (requires kernel preemption).Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).A concerted effort at support for portable computers.
This is somewhat handled by changing PCMCIA bridging rules
and power management event handling. But there are things
like detecting internal vs. external display and picking a
different screen resolution based on that fact, not spinning
down the disk if the machine is in dock, and allowing
dock-based cards to disappear without affecting the machines
ability to boot (same issue for PCMCIA).Reorganization of the source tree for multiple platform
ports.A make world that "makes the world" (rename the
current one to make regress if that is all it is good
for).A 4M (preferably smaller!) memory footprint.Smaller tasksMost of the tasks listed in the previous sections require
either a considerable investment of time or an in-depth knowledge
of the FreeBSD kernel (or both). However, there are also many
useful tasks which are suitable for "weekend hackers",
or people without programming skills.If you run FreeBSD-current and have a good Internet
connection, there is a machine current.freebsd.org which
builds a full release once a day — every now and again, try
and install the latest release from it and report any
failures in the process.Read the freebsd-bugs mailing list. There might be a
problem you can comment constructively on or with patches
you can test. Or you could even try to fix one of the
problems yourself.Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even just
completely wrong, let us know. Even better, send us a fix
(SGML is not difficult to learn, but there is no objection
to ASCII submissions).Help translate FreeBSD documentation into your native
language (if not already available) — just send an email to
&a.doc; asking if anyone is working on it. Note that you
are not committing yourself to translating every single
FreeBSD document by doing this — in fact, the documentation
most in need of translation is the installation
instructions.Read the freebsd-questions mailing list and the
newsgroup comp.unix.bsd.freebsd.misc occasionally (or even
regularly). It can be very satisfying to share your
expertise and help people solve their problems; sometimes
you may even learn something new yourself! These forums can
also be a source of ideas for things to work on.If you know of any bugfixes which have been successfully
applied to -current but have not been merged into -stable
after a decent interval (normally a couple of weeks), send
the committer a polite reminder.Move contributed software to
src/contrib in the source tree.Make sure code in src/contrib is up
to date.Look for year 2000 bugs (and fix any you find!)Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.If you have contributed any ports, send your patches
back to the original author (this will make your life easier
when they bring out the next version)Suggest further tasks for this list!How to ContributeContributions to the system generally fall into one or more of
the following 6 categories:Bug reports and general commentaryAn idea or suggestion of general
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
high volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
mailing lists for more
information about this and other mailing lists.If you find a bug or are submitting a specific change, please
report it using the send-pr1program or its
WEB-based
equivalent. Try to fill-in each field of the bug report.
Unless they exceed 65KB, include any patches directly in the
report. Consider compressing them and using
uuencode1 if they exceed 20KB. Upload very large submissions to ftp.freebsd.org:/pub/FreeBSD/incoming/.After filing a report, you should receive confirmation along
with a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to bug-followup@FreeBSD.ORG. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way.If you do not receive confirmation in a timely fashion (3 days
to a week, depending on your email connection) or are, for some
reason, unable to use the send-pr1 command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.Changes to the documentationChanges to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
send-pr as described in
Bug Reports and General
Commentary.Changes to existing source codeAn addition or change to the existing source code is a
somewhat trickier affair and depends a lot on how far out of date
you are with the current state of the core FreeBSD development.
There is a special on-going release of FreeBSD known as
“FreeBSD-current” which is made available in a variety of ways
for the convenience of developers working actively on the system.
See Staying current with FreeBSD
for more information
about getting and using FreeBSD-current.Working from older sources unfortunately means that your
changes may sometimes be too obsolete or too divergent for easy
re-integration into FreeBSD. Chances of this can be minimized
somewhat by subscribing to the &a.announce; and the &a.current;
lists, where discussions on the current state of the system take
place.Assuming that you can manage to secure fairly up-to-date
sources to base your changes on, the next step is to produce a set
of diffs to send to the FreeBSD maintainers. This is done with
the diff1 command, with the “context diff”
form being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; diff -c -r olddir newdir
would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for diff1 for more details.Once you have a set of diffs (which you may test with the
patch1 command), you should submit them for
inclusion with FreeBSD. Use the send-pr1
program as described in
Bug Reports and General
Commentary. Do not just send the diffs to
the &a.hackers; or they will get lost! We greatly appreciate your
submission (this is a volunteer project!); because we are busy, we
may not be able to address it immediately, but it will remain in
the pr database until we do.If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file and run the
uuencode1 program on it. Shar archives are
also welcome.If your change is of a potentially sensitive nature, e.g. you
are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review
first, then you should send it to &a.core; directly rather than
submitting it with send-pr1. The core
mailing list reaches a much smaller group of people who do much of
the day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to
them where it is truly necessary.Please refer to man 9 intro and
man 9 style for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.New code or major value-added packagesIn the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD, it
becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:The BSD copyright. This copyright is most preferred due
to its “no strings attached” nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial
interests who might eventually be inclined to invest
something of their own into FreeBSD.The GNU Public License, or “GPL”. This license is not
quite as popular with us due to the amount of extra effort
demanded of anyone using the code for commercial purposes,
but given the sheer quantity of GPL'd code we currently
require (compiler, assembler, text formatter, etc) it would
be silly to refuse additional contributions under this
license. Code under the GPL also goes into a different part
of the tree, that being /sys/gnu or
/usr/src/gnu, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will be
considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.To place a “BSD-style” copyright on your work, include the
following text at the very beginning of every source code file you
wish to protect, replacing the text between the
%% with the appropriate information.
Copyright (c) %%proper_years_here%%
%%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$For your convenience, a copy of this text can
be found in
/usr/share/examples/etc/bsd-style-copyright.Money, Hardware or Internet accessWe are always very happy to accept donations to further the
cause of the FreeBSD Project and, in a volunteer effort like ours,
a little can go a long way! Donations of hardware are also very
important to expanding our list of supported peripherals since we
generally lack the funds to buy such items ourselves.Donating fundsWhile the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.dg; with the goal of furthering the aims of the FreeBSD
Project and giving it a minimal corporate presence. Any and all
funds donated (as well as any profits that may eventually be
realized by FreeBSD, Inc.) will be used exclusively to further
the project's goals.Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:FreeBSD, Inc.c/o Jordan Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO
box can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to
Jordan Hubbard jkh@FreeBSD.org,
either via email or to the FreeBSD, Inc. postal address given
above.If you do not wish to be listed in our donors section, please specify this
when making your donation. Thanks!Donating hardwareDonations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the donating funds
section.Hardware for which ongoing compliance testing is
desired. We are currently trying to put together a testing
lab of all components that FreeBSD supports so that proper
regression testing can be done with each new release. We
are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a
donation, please contact &a.dg; for information on
which items are still required.Hardware currently unsupported by FreeBSD for which
you would like to see such support added. Please contact
the &a.core; before sending such items as we will need to
find a developer willing to take on the task before we can
accept delivery of new hardware.Donating Internet accessWe can always use new mirror sites for FTP, WWW or cvsup. If
you would like to be such a mirror, please contact the FreeBSD project
administrators admin@FreeBSD.ORG for more information.Donors GalleryThe FreeBSD Project is indebted to the following donors and
would like to publically thank them here!Contributors to the central server
project:The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
freefall.freebsd.org by donating the
following items:Ade
Barkah mbarkah@freebsd.org and his employer, Hemisphere Online,
donated a Pentium Pro (P6) 200Mhz
CPUASA
Computers donated a Tyan
1662 motherboard.Joe McGuckin joe@via.net
of ViaNet
Communications donated a Kingston ethernet controller.Jack
O'Neill jack@diamond.xtalwind.net donated an NCR
53C875 SCSI controller card.Ulf
Zimmermann ulf@Alameda.net of Alameda Networks
donated 128MB of memory, a
4 Gb disk drive and the
case.Direct funding:The following individuals and businesses have generously
contributed direct funding to the project:Annelise
Anderson ANDRSN@HOOVER.STANFORD.EDUMatt
Dillon dillon@best.netEpilogue
Technology CorporationSean Eric FaganDon Scott WildeGianmarco
Giovannelli gmarco@masternet.itJosef C.
Grosch joeg@truenorth.orgRobert T. MorrisChuck
Robey chuckr@freebsd.orgKenneth
P. Stox ken@stox.sa.enteract.com of Imaginary Landscape,
LLC.Dmitry S.
Kohmanyuk dk@dog.farm.orgLaser5
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.Fuki
Shuppan Publishing Co. donated a portion of
their profits from Hajimete no
FreeBSD (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.ASCII
Corp. donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.Yokogawa
Electric Corp has generously donated
significant funding to the FreeBSD project.BuffNET
+
+ Pacific
+ Solutions
+ Hardware contributors:The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:Walnut Creek CDROM for providing the Pentium P5-90
and 486/DX2-66 EISA/VL systems that are being used for
our development work, to say nothing of the network
access and other donations of hardware resources.TRW Financial Systems, Inc. provided 130 PCs, three
68 GB fileservers, twelve Ethernets, two routers and an
ATM switch for debugging the diskless code. They also
keep a couple of FreeBSD hackers alive and busy.
Thanks!Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.&a.chuck; contributed his floppy tape streamer for
experimental work.Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver.Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-)Tekram
Technologies sent one each of their DC-390,
DC-390U and DC-390F FAST and ULTRA SCSI host adapter
cards for regression testing of the NCR and AMD drivers
with their cards. They are also to be applauded for
making driver sources for free operating systems
available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD.Larry M.
Augustin contributed not only a Symbios
Sym8751S SCSI card, but also a set of data books,
including one about the forthcoming Sym53c895 chip with
Ultra-2 and LVD support, and the latest programming
manual with information on how to safely use the
advanced features of the latest Symbios SCSI chips.
Thanks a lot!Christoph
Kukulies kuku@freebsd.org donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.Special contributors:Walnut Creek
CDROM has donated almost more than we can say
(see the
history document for
more details). In particular, we would like to thank
them for the original hardware used for
freefall.FreeBSD.ORG, our primary
development machine, and for
thud.FreeBSD.ORG, a testing and
build box. We are also indebted to them for funding
various contributors over the years and providing us
with unrestricted use of their T1 connection to the
Internet.The interface
business GmbH, Dresden has been patiently
supporting &a.joerg; who has often preferred FreeBSD
work over paywork, and used to fall back to their (quite
expensive) EUnet Internet connection whenever his
private connection became too slow or flakey to work
with it...Berkeley Software
Design, Inc. has contributed their DOS
emulator code to the remaining BSD world, which is used
in the dosemu command.Derived Software ContributorsThis software was originally derived from William F. Jolitz's
386BSD release 0.1, though almost none of the original 386BSD
specific code remains. This software has been essentially
re-implemented from the 4.4BSD-Lite release provided by the Computer
Science Research Group (CSRG) at the University of California,
Berkeley and associated academic contributors.There are also portions of NetBSD and OpenBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAda T Lim ada@bsd.orgAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian T. Filipi-Martin atf3r@agate.cs.virginia.eduAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker A.C.P.M.Kalker@student.utwente.nlAlan Cox alc@cs.rice.eduAmancio Hasty ahasty@freebsd.orgAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndrew Gallatin gallatin@cs.duke.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew McRae amcrae@cisco.comAndrew Moore alm@FreeBSD.orgAndrew Stevenson andrew@ugh.net.auAndrew V. Stesin stesin@elvisti.kiev.uaAndrey Zakhvatov andy@icc.surw.chel.suAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.com
-
+
+
+ Anton Berezin tobez@plab.ku.dk
+
+
Ari Suutari ari@suutari.iki.fiBen Hutchinson benhutch@xfiles.org.ukBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBrandon Gillespie brandon@roguetrader.com&a.wlloyd;Bob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Taylor brett@peloton.physics.montana.eduBrian Clapper bmc@willscreek.com
-
+
+
+ Brian F. Feldman green@unixhelp.org
+
+
Brian Handy handy@lambic.space.lockheed.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce Gingery bgingery@gtcs.comBruce Mah bmah@ca.sandia.govCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCharles Hannum mycroft@ai.mit.eduCharles Mott cmott@srv.netChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChris Dabrowski chris@vader.orgChris G. Demetriou cgd@postgres.berkeley.eduChris Shenton cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristoph Robitschko chmr@edvz.tu-graz.ac.atChristopher T. Johnson
cjohnson@neunacht.netgsi.comChoi Jun Ho junker@jazz.snu.ac.krChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGConrad Sabatier conrads@neosoft.comCornelis van der Laan nils@guru.ims.uni-stuttgart.deCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comDai Ishijima ishijima@tri.pref.osaka.jpDan Cross tenser@spitfire.ecsel.psu.eduDaniel Baker dbaker@crash.ops.neosoft.comDaniel M. Eischen deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDanny J. Zerkel dzerkel@feephi.phofarm.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Edmondson davided@sco.comDave Rivers rivers@ponds.uucpDavid A. Bader dbader@umiacs.umd.eduDavid Dawes dawes@physics.su.OZ.AUDavid Holloway daveh@gwythaint.tamis.comDavid Leonard d@scry.dstc.edu.auDean Huxley dean@fsa.ca
-
+
+
+ Dima Sivachenko demon@gpad.ac.ru
+
+
Dirk Froemberg dirk@hal.in-berlin.deDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Yuniskis dgy@rtd.comDonald Maddox dmaddox@scsn.netDoug Ambrisko ambrisko@ambrisko.roble.comDouglas Carmichael dcarmich@mcs.comEckart “Isegrim” Hofmann
Isegrim@Wunder-Nett.orgEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Chet ejc@bazzle.comEric J. Schwertfeger eric@cybernut.comFrancis M J Hsieh mjhsieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan frankch@waru.life.nthu.edu.twFrank Maclachlan fpm@crash.cts.comFrank Nobis fn@trinity.radio-do.deFrank Volf volf@oasis.IAEhv.nlFUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jpFURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jpGary A. Browning gab10@griffcd.amdahl.comGary Kline kline@thought.orgGerard Roudier groudier@club-internet.frGilad Rom rom_glsa@ein-hashofet.co.ukGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGlenn Johnson gljohns@bellsouth.netGreg Ungerer gerg@stallion.oz.auHans Huebner hans@artcom.deHans Petter Bieker hanspb@persbraten.vgs.noHarlan Stenn Harlan.Stenn@pfcs.comHavard Eidnes Havard.Eidnes@runit.sintef.noHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jp
-
- Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
-
-
Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+
+
Hironori Ikura hikura@kaisei.orgHiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jpHolger Veit Holger.Veit@gmd.deHONDA Yasuhiro honda@kashio.info.mie-u.ac.jpHorance Chou horance@freedom.ie.cycu.edu.twHung-Chi Chu hcchu@r350.ee.ntu.edu.twIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jpIshii MasahiroIseei Suzuki issei@jp.FreeBSD.ORGItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. David Lowe lowe@saturn5.comJ. Han jtc@cygnus.comJ.T. Conklin jtc@cygnus.comJ.T. Lang keith@email.gcn.net.twJames Clark jjc@jclark.comJames da Silva jds@cs.umd.edu et alJanusz Kokot janek@gaja.ipan.lublin.plJason Thorpe thorpej@nas.nasa.govJavier Martin Rueda jmrueda@diatel.upm.esJeff Bartig jeffb@doit.wisc.eduKeff Kletsky Jeff@Wagsky.comJeffrey Wheat jeff@cetlink.netJeremy Lea reg@shale.csir.co.zaJerry Hicks jhicks@glenatl.glenayre.comJian-Da Li jdli@csie.NCTU.edu.twJim Binkley jrb@cs.pdx.eduJim Lowe james@cs.uwm.edu
-
+
+
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld/orgJoao Carlos Mendes Luis jonny@coppe.ufrj.br
+
+ Joe Abley jabley@clear.co.nz
+
+
Joe “Marcus” Clarke
marcus@miami.eduJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoel Sutton sutton@aardvark.apana.org.auJohann Tonsing jtonsing@mikom.csir.co.zaJohn Capo jc@irbs.comJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Perry perry@vishnu.alias.netJohn Polstra jdp@polstra.comJohn Rochester jr@cs.mun.caJohn Saunders john@pacer.nlc.net.auJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJosef Karthauser joe@uk.freebsd.orgJoseph Stein joes@seaport.netJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJulian Assange proff@suburbia.netJulian Jenkins kaveman@magna.com.auJulian Stacey jhs@freebsd.orgJunichi Satoh junichi@jp.freebsd.orgJunya WATANABE junya-w@remus.dti.ne.jpKapil Chowksey kchowksey@hss.hns.comKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKeith Bostic bostic@bostic.comKeith MooreKenneth Monville desmo@bandwidth.orgKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKirk McKusick mckusick@mckusick.comKiroh HARADA kiroh@kh.rim.or.jpKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.su
-
+
+
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+
+
Kurt Olsen kurto@tiny.mcs.usu.eduLars Köller Lars.Koeller@Uni-Bielefeld.DELian Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twuLucas James Lucas.James@ldjpc.apana.org.auLuigi Rizzo luigi@iet.unipi.it
-
+
+
+ Malte Lance malte.lance@gmx.net
+
+
Makoto MATSUSHITA matusita@jp.freebsd.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jp
+
+
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ Manu Iyengar iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMario Sergio Fujikawa Ferreira lioux@gns.com.brMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin BirgmeierMartti Kuparinen erakupa@kk.etx.ericsson.seMasachika ISHIZUKA ishizuka@isis.min.ntt.jpMasanori Kiriake seiken@ncs.co.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas thomas@lkg.dec.comMatt White mwhite+@CMU.EDUMatthew N. Dodd winter@jurai.netMatthew Stein matt@bdd.netMaurice Castro maurice@planet.serc.rmit.edu.auMichael Butschky butsch@computi.erols.comMichael Elbel me@FreeBSD.ORGMichael Searle searle@longacre.demon.co.ukMiguel Angel Sagreras msagre@cactus.fi.uba.arMikael Hybsch micke@dynas.seMikhail Teterin mi@aldan.ziplink.netMike McGaughey mmcg@cs.monash.edu.auMike Peck mike@binghamton.eduMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMITA Yoshio mita@jp.FreeBSD.ORGMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMotoyuki Kasahara m-hasahr@sra.co.jp
+
+
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.comNAKAMURA Kazushi nkazushi@highway.or.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNIIMI Satoshi sa2c@and.or.jpNick Sayer nsayer@quack.kfu.comNicolas Souchu Nicolas.Souchu@prism.uvsq.frNisha Talagala nisha@cs.berkeley.eduNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
+
+
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+
+
Noritaka Ishizumi graphite@jp.FreeBSD.ORGOliver Breuninger ob@seicom.NETOliver Fromme oliver.fromme@heim3.tu-clausthal.deOliver Laumann net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.com
-
+
+
+ Palle Girgensohn girgen@partitur.se
+
+
Paul Fox pgf@foxharp.boston.ma.usPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaulo Menezes paulo@isr.uc.ptPaul T. Root proot@horton.iaces.comPedro Giffuni giffunip@asme.orgPedro A M Vazquez vazquez@IQM.Unicamp.BRPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Stubbs PETERS@staidan.qld.edu.auPierre Beyssac bp@fasterix.freenix.orgPhil Maker pjm@cs.ntu.edu.auR. Kym HorsellRandall Hopper rhh@stealth.ct.picker.comRicardas Cepas rch@richard.eu.orgRichard Hwang rhwang@bigpanda.comRichard. M. Neswold rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Wiwatowski rjwiwat@adelaide.on.netRob Mallory rmallory@csusb.eduRob Shady rls@id.netRob Snow rsnow@txdirect.netRobert Sanders rsanders@mindspring.comRobert Withrow witr@rwwa.comRonald Kuehn kuehn@rz.tu-clausthal.deRoland Jesse jesse@cs.uni-magdeburg.deRuslan Shevchenko rssh@cki.ipri.kiev.uaSURANYI Peter suranyip@jks.is.tsukuba.ac.jpSamuel Lam skl@ScalableNetwork.comSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+
+ Satsuki FUJISHIMA k5@respo.or.jp
+
+
Scot W. Hetzel hetzels@westbend.netScott Blachowicz scott.blachowicz@seaslug.orgScott A. Kenney saken@rmta.ml.orgSeigou TANIMURA
tanimura@naklab.dnj.ynu.ac.jp
-
- Seiichirou Hiraoka flathill@flathill.gr.jp
-
-
Serge Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSheldon Hearn axl@iafrica.comShigeyuki FUKUSHIMA
shige@kuis.kyoto-u.ac.jpSimon Marlow simonm@dcs.gla.ac.ukSlaven Rezic (Tomic) eserte@cs.tu-berlin.deSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan “Sec” Zehl sec@42.orgStephane Legrand stephane@lituus.frStephen Farrell stephen@farrell.orgStephen J. Roznowski sjr@home.netSteve Gerakines steve2@genesis.tiac.netSteven G. Kargl
kargl@troutmask.apl.washington.eduStephen H. Samorodin samorodi@NUXU.comStuart Henderson
stuart@internationalschool.co.uk
+
+
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeu NAIKI naiki@bfd.es.hokudai.ac.jpTed Faber faber@ISI.EDUTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo Deraadt deraadt@fsa.caThomas König Thomas.Koenig@ciw.uni-karlsruhe.deÞórður Ívarsson totii@est.isTim Kientzle kientzle@netcom.comTim Wilkinson tim@sarc.city.ac.uk
+
+ Tom Hukins tom@eborcom.com
+
+
Tom Jobbins tom@tom.tjTom Samplonius tom@misery.sdf.comTorbjorn Granlund tege@matematik.su.seToshihiro Kanda candy@fct.kgc.co.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpTrefor S. trefor@flevel.co.uk
-
+
+
+ Vadim Chekan vadim@gc.lviv.ua
+
+
Ville Eerola ve@sci.fiVladimir Kushnir kushn@mail.kar.netWerner Griessl werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWilko Bulte wilko@yedi.iaf.nlWolfgang Stanglmeier wolf@kintaro.cologne.deWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshiro Mihira sanpei@yy.cs.keio.ac.jp
- Yukihiro Nakai nakai@technologist.com
+ Yukihiro Nakai nakai@iname.comYusuke Nawano azuki@azkey.orgYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nl386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse lohse@tech7.informatik.uni-hamburg.deJörg Wunsch joerg_wunsch@uriah.heep.sax.deJohn Dyson formerly
dyson@ref.tfs.comJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@freebsd.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.ORGRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO8859-1/books/handbook/authors.ent b/en_US.ISO8859-1/books/handbook/authors.ent
index 80e0daca31..374e7dca88 100644
--- a/en_US.ISO8859-1/books/handbook/authors.ent
+++ b/en_US.ISO8859-1/books/handbook/authors.ent
@@ -1,326 +1,338 @@
abial@FreeBSD.ORG">
ache@FreeBSD.ORG">
adam@FreeBSD.ORG">
alex@freebsd.org">
amurai@FreeBSD.ORG">
andreas@FreeBSD.ORG">
archie@FreeBSD.ORG">
asami@FreeBSD.ORG">
ats@FreeBSD.ORG">
awebster@pubnix.net">
bde@FreeBSD.ORG">
billf@FreeBSD.ORG">
brandon@FreeBSD.ORG">
brian@FreeBSD.ORG">
cawimm@FreeBSD.ORG">
charnier@FreeBSD.ORG">
chuckr@glue.umd.edu">
chuckr@FreeBSD.ORG">
cracauer@FreeBSD.ORG">
csgr@FreeBSD.ORG">
cwt@FreeBSD.ORG">
danny@FreeBSD.ORG">
darrenr@FreeBSD.ORG">
dg@FreeBSD.ORG">
davidn@blaze.net.au">
dburr@FreeBSD.ORG">
des@FreeBSD.ORG">
dfr@FreeBSD.ORG">
dillon@FreeBSD.ORG">
dima@FreeBSD.ORG">
+dirk@FreeBSD.ORG">
+
Dirk.vanGulik@jrc.it">
dt@FreeBSD.ORG">
dwhite@FreeBSD.ORG">
dufault@FreeBSD.ORG">
dyson@FreeBSD.ORG">
perhaps@yes.no">
ejc@FreeBSD.ORG">
erich@FreeBSD.ORG">
faq@freebsd.org">
fenner@FreeBSD.ORG">
flathill@FreeBSD.ORG">
+foxfair@FreeBSD.ORG">
+
fsmp@FreeBSD.ORG">
+gallatin@FreeBSD.ORG">
+
gclarkii@FreeBSD.ORG">
gena@NetVision.net.il">
ghelmer@cs.iastate.edu">
gibbs@FreeBSD.ORG">
mjacob@FreeBSD.ORG">
gj@FreeBSD.ORG">
gpalmer@FreeBSD.ORG">
graichen@FreeBSD.ORG">
grog@FreeBSD.ORG">
gryphon@healer.com">
guido@FreeBSD.ORG">
hanai@FreeBSD.ORG">
handy@sxt4.physics.montana.edu">
helbig@FreeBSD.ORG">
-hm@kts.org">
+hm@FreeBSD.ORG">
hoek@FreeBSD.ORG">
hosokawa@FreeBSD.ORG">
hsu@FreeBSD.ORG">
imp@FreeBSD.ORG">
itojun@itojun.org">
jb@cimlogic.com.au">
jdp@FreeBSD.ORG">
jehamby@lightside.com">
jfieber@FreeBSD.ORG">
james@nexis.net">
jgreco@FreeBSD.ORG">
jhay@FreeBSD.ORG">
jkh@FreeBSD.ORG">
jkoshy@FreeBSD.ORG">
jlemon@FreeBSD.ORG">
john@starfire.MN.ORG">
jlrobin@FreeBSD.ORG">
jmacd@FreeBSD.ORG">
jmb@FreeBSD.ORG">
jmg@FreeBSD.ORG">
jmz@FreeBSD.ORG">
joerg@FreeBSD.ORG">
john@FreeBSD.ORG">
jraynard@freebsd.org">
jseger@freebsd.org">
julian@FreeBSD.ORG">
jvh@FreeBSD.ORG">
karl@FreeBSD.ORG">
kato@FreeBSD.ORG">
kelly@fsl.noaa.gov">
ken@FreeBSD.ORG">
kjc@FreeBSD.ORG">
kuriyama@FreeBSD.ORG">
lars@FreeBSD.ORG">
ljo@FreeBSD.ORG">
luoqi@FreeBSD.ORG">
markm@FreeBSD.ORG">
martin@FreeBSD.ORG">
max@FreeBSD.ORG">
mark@vmunix.com">
mbarkah@FreeBSD.ORG">
mckay@FreeBSD.ORG">
mckusick@FreeBSD.ORG">
md@bsc.no">
+mks@FreeBSD.ORG">
+
motoyuki@FreeBSD.ORG">
mph@FreeBSD.ORG">
mpp@FreeBSD.ORG">
msmith@FreeBSD.ORG">
nate@FreeBSD.ORG">
nectar@FreeBSD.ORG">
+newton@FreeBSD.ORG">
+
n_hibma@FreeBSD.ORG">
nik@FreeBSD.ORG">
nsj@FreeBSD.ORG">
obrien@FreeBSD.ORG">
olah@FreeBSD.ORG">
opsys@open-systems.net">
paul@FreeBSD.ORG">
pb@fasterix.freenix.org">
pds@FreeBSD.ORG">
peter@FreeBSD.ORG">
phk@FreeBSD.ORG">
pjchilds@imforei.apana.org.au">
proven@FreeBSD.ORG">
pst@FreeBSD.ORG">
rgrimes@FreeBSD.ORG">
rhuff@cybercom.net">
ricardag@ag.com.br">
rich@FreeBSD.ORG">
rnordier@FreeBSD.ORG">
roberto@FreeBSD.ORG">
rse@FreeBSD.ORG">
sada@FreeBSD.ORG">
scrappy@FreeBSD.ORG">
se@FreeBSD.ORG">
sef@FreeBSD.ORG">
+simokawa@FreeBSD.ORG">
+
smace@FreeBSD.ORG">
smpatel@FreeBSD.ORG">
sos@FreeBSD.ORG">
stark@FreeBSD.ORG">
stb@FreeBSD.ORG">
steve@FreeBSD.ORG">
swallace@FreeBSD.ORG">
tedm@FreeBSD.ORG">
tegge@FreeBSD.ORG">
tg@FreeBSD.ORG">
thepish@FreeBSD.ORG">
torstenb@FreeBSD.ORG">
truckman@FreeBSD.ORG">
ugen@FreeBSD.ORG">
uhclem@FreeBSD.ORG">
ulf@FreeBSD.ORG">
vanilla@FreeBSD.ORG">
wes@FreeBSD.ORG">
whiteside@acm.org">
wilko@yedi.iaf.nl">
wlloyd@mpd.ca">
wollman@FreeBSD.ORG">
wosch@FreeBSD.ORG">
wpaul@FreeBSD.ORG">
yokota@FreeBSD.ORG">
diff --git a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
index a549e0ca67..64de53ef79 100644
--- a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
@@ -1,506 +1,531 @@
BibliographyWhile the manual pages provide the definitive reference for
individual pieces of the FreeBSD operating system, they are notorious
for not illustrating how to put the pieces together to make the whole
operating system run smoothly. For this, there is no substitute for a
good book on UNIX system administration and a good users'
manual.Books & Magazines Specific to FreeBSDInternational books &
Magazines:Using
FreeBSD (in Chinese).FreeBSD for PC 98'ers (in Japanese), published by SHUWA
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.FreeBSD (in Japanese), published by CUTT. ISBN
4-906391-22-2 C3055 P2400E.Complete Introduction to FreeBSD (in Japanese), published by Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E.Personal UNIX Starter Kit FreeBSD (in Japanese), published by ASCII. ISBN 4-7561-1733-3 P3000E.FreeBSD Handbook (Japanese translation), published by
ASCII. ISBN
4-7561-1580-2 P3800E.
- FreeBSD mit Methode (in German), publiched by Computer und
- Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-93211-31-0.
+ FreeBSD mit Methode (in German), published by Computer und
+ Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.
+
+
+ FreeBSD
+ Install and Utilization Manual (in Japanese),
+ published by Mainichi
+ Communications Inc..
+ English language books &
Magazines:The
Complete FreeBSD, published by Walnut Creek
CDROM.Users' GuidesComputer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-075-9Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-076-7UNIX in a Nutshell. O'Reilly
& Associates, Inc., 1990. ISBN
093717520XMui, Linda. What You Need To Know When You Can't
Find Your UNIX System Administrator. O'Reilly
& Associates, Inc., 1995. ISBN 1-56592-104-6Ohio State
University has written a UNIX Introductory Course which is available online in HTML and postscript format.
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ User's Reference Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0088-4
+ P3800E.
+ Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc.,
1997. ISBN 1-56592-236-0Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-080-5Costales, Brian, et al. Sendmail, 2nd
Ed. O'Reilly & Associates, Inc., 1997. ISBN
1-56592-222-0Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly &
Associates, Inc., 1995. ISBN 1-56592-127-5Hunt, Craig. TCP/IP Network
Administration. O'Reilly & Associates, Inc.,
1992. ISBN 0-937175-82-XNemeth, Evi. UNIX System Administration
Handbook. 2nd Ed. Prentice Hall, 1995. ISBN 0131510517Stern, Hal Managing NFS and NIS
O'Reilly & Associates, Inc., 1991. ISBN
0-937175-75-7
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ System Administrator's Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0109-0
+ P3300E.
+ Programmers' GuidesAsente, Paul. X Window System
Toolkit. Digital Press. ISBN
1-55558-051-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-078-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary
Documents. O'Reilly & Associates, Inc., 1994.
ISBN 1-56592-079-1Harbison, Samuel P. and Steele, Guy L. Jr. C: A
Reference Manual. 4rd ed. Prentice Hall, 1995.
ISBN 0-13-326224-3Kernighan, Brian and Dennis M. Ritchie. The C
Programming Language.. PTR Prentice Hall, 1988.
ISBN 0-13-110362-9Lehey, Greg. Porting UNIX Software.
O'Reilly & Associates, Inc., 1995. ISBN
1-56592-126-7Plauger, P. J. The Standard C
Library. Prentice Hall, 1992. ISBN
0-13-131509-9Stevens, W. Richard. Advanced Programming in the
UNIX Environment. Reading, Mass. :
Addison-Wesley, 1992 ISBN 0-201-56317-7Stevens, W. Richard. UNIX Network
Programming. 2nd Ed, PTR Prentice Hall, 1998. ISBN
0-13-490012-XWells, Bill. “Writing Serial Drivers for UNIX”.
Dr. Dobb's Journal. 19(15), December
1994. pp68-71, 97-99.Operating System InternalsAndleigh, Prabhat K. UNIX System
Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5Jolitz, William. “Porting UNIX to the
386”. Dr.
Dobb's Journal. January 1991-July 1992.Leffler, Samuel J., Marshall Kirk McKusick, Michael J
Karels and John Quarterman The Design and
Implementation of the 4.3BSD UNIX Operating
System. Reading, Mass. : Addison-Wesley,
1989. ISBN 0-201-06196-1Leffler, Samuel J., Marshall Kirk McKusick, The
Design and Implementation of the 4.3BSD UNIX Operating
System: Answer Book. Reading, Mass. :
Addison-Wesley, 1991. ISBN 0-201-54629-9McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation
of the 4.4BSD Operating System. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-54979-4Stevens, W. Richard. TCP/IP Illustrated, Volume
1: The Protocols. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-63346-9Schimmel, Curt. Unix Systems for Modern
Architectures. Reading, Mass. : Addison-Wesley,
1994. ISBN 0-201-63338-8Stevens, W. Richard. TCP/IP Illustrated, Volume
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
Protocols. Reading, Mass. : Addison-Wesley,
1996. ISBN 0-201-63495-3Vahalia, Uresh. UNIX Internals -- The New
Frontiers. Prentice Hall, 1996. ISBN
0-13-101908-2Wright, Gary R. and W. Richard Stevens. TCP/IP
Illustrated, Volume 2: The Implementation.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63354-XSecurity ReferenceCheswick, William R. and Steven M. Bellovin.
Firewalls and Internet Security: Repelling the Wily
Hacker. Reading, Mass. : Addison-Wesley,
1995. ISBN 0-201-63357-4Garfinkel, Simson and Gene Spafford. Practical
UNIX Security. 2nd Ed. O'Reilly & Associates,
Inc., 1996. ISBN 1-56592-148-8Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995.
ISBN 1-56592-098-8Hardware ReferenceAnderson, Don and Tom Shanley. Pentium Processor
System Architecture. 2nd Ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40992-5Ferraro, Richard F. Programmer's Guide to the
EGA, VGA, and Super VGA Cards. 3rd ed. Reading,
Mass. : Addison-Wesley, 1995. ISBN
0-201-62490-7Intel Corporation publishes documentation on their CPUs,
chipsets and standards on their developer web site,
usually as PDF files.Shanley, Tom. 80486 System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40994-1Shanley, Tom. ISA System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40996-8Shanley, Tom. PCI System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40993-3Van Gilluwe, Frank. The Undocumented
PC. Reading, Mass: Addison-Wesley Pub. Co.,
1994. ISBN 0-201-62277-7UNIX HistoryLion, John Lion's Commentary on UNIX, 6th Ed.
With Source Code. ITP Media Group, 1996. ISBN 1573980137Raymond, Eric s. The New Hacker's Dictonary, 3rd
edition. MIT Press, 1996. ISBN
0-262-68092-0 Also known as the Jargon
FileSalus, Peter H. A quarter century of
UNIX. Addison-Wesley Publishing Company, Inc.,
1994. ISBN 0-201-54777-5Simon Garfinkel, Daniel Weise, Steven Strassmann.
The UNIX-HATERS Handbook. IDG Books
Worldwide, Inc., 1994. ISBN 1-56884-203-1Don Libes, Sandy Ressler Life with
UNIX — special edition. Prentice-Hall, Inc.,
1989. ISBN 0-13-536657-7The BSD family tree. 1997. ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree or local on a FreeBSD-current machine.The BSD Release Announcements
collection. 1997. http://www.de.FreeBSD.ORG/de/ftp/releases/Networked Computer Science Technical Reports
Library. http://www.ncstrl.org/Old BSD releases from the Computer Systems Research
group (CSRG). http://www.mckusick.com/csrg/: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last disk holds the final sources plus the SCCS files.Magazines and JournalsThe C/C++ Users Journal. R&D
Publications Inc. ISSN 1075-2838Sys Admin — The Journal for UNIX System
Administrators Miller Freeman, Inc., ISSN
1061-2688
diff --git a/en_US.ISO8859-1/books/handbook/book.sgml b/en_US.ISO8859-1/books/handbook/book.sgml
index a4c9c067df..fb72c6e754 100644
--- a/en_US.ISO8859-1/books/handbook/book.sgml
+++ b/en_US.ISO8859-1/books/handbook/book.sgml
@@ -1,111 +1,112 @@
%chapters;
%authors;
%mailing-lists;
]>
FreeBSD HandbookThe FreeBSD Documentation ProjectJuly 19981995199619971998The FreeBSD Documentation Project, FreeBSD Inc.Welcome to FreeBSD! This handbook covers the installation and day
to day use of FreeBSD Release &rel.current;. This
manual is a work in progress and is the work of
many individuals. Many sections do not yet exist and some of those
that do exist need to be updated. If you are interested in helping
- with this project, send email to the &a.doc; The latest version of
+ with this project, send email to the &a.doc;. The latest version of
this document is always available from the FreeBSD World Wide Web server.
It may also be downloaded in plain
text, postscript or HTML with HTTP or gzip'd from the FreeBSD FTP server or one of the numerous FreeBSD FTP server or one of the numerous mirror sites. You may also want to
Search the Handbook.Getting Started
&chap.introduction;
&chap.install;
&chap.basics;
&chap.ports
System Administration
&chap.kernelconfig;
&chap.security;
&chap.printing;
&chap.disks;
&chap.backups;
&chap.quotas;
&chap.x11;
&chap.hw;
&chap.l10n;
Network Communications
&chap.serialcomms;
&chap.ppp-and-slip;
&chap.advanced-networking;
&chap.mail;
Advanced topics
&chap.cutting-edge;
&chap.contrib;
&chap.policies;
&chap.kernelopts;
&chap.kerneldebug;
&chap.linuxemu;
&chap.internals;
Appendices
&chap.mirrors;
&chap.bibliography;
&chap.eresources;
&chap.staff;
&chap.pgpkeys;
diff --git a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
index 2dffa913a2..bd3723e510 100644
--- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
@@ -1,2895 +1,2954 @@
Contributing to FreeBSDContributed by &a.jkh;.So you want to contribute something to FreeBSD? That is great! We
can always use the help, and FreeBSD is one of those systems that
relies on the contributions of its user base in
order to survive. Your contributions are not only appreciated, they
are vital to FreeBSD's continued growth!Contrary to what some people might also have you believe, you do
not need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help
the project!Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product?
Please let us know! We may be able to work cooperatively on some
aspect of it. The free software world is challenging a lot of
existing assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at least give
it a second look.What Is NeededThe following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user
requests we have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If you are
interested in working on one of the tasks you see here, send mail to
the coordinator listed by clicking on their names. If no
coordinator has been appointed, maybe you would like to
volunteer?High priority tasksThe following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:3-stage boot issues. Overall coordination:
&a.hackers;Move userconfig (-c) into 3rd stage boot.Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.Filesystem problems. Overall coordination: &a.fs;Fix the MSDOS file system.Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;Fix the union file system. Coordinator:
&a.dg;Implement kernel and user vm86 support. Coordinator:
&a.jlemon;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;Kernel issues. Overall coordination: &a.hackers;Complete the eisaconf conversion of all existing
drivers.Change all interrupt routines to take a (void *)
instead of using unit numbers.Merge EISA/PCI/ISA interrupt registration
code.Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).Medium priority tasksThe following tasks need to be done, but not with any
particular urgency:Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth Jones ajones@ctron.comMCA support? This should be finalized one way or the
other.Full LKM based driver support/Configuration Manager.Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;Documentation!Reliable operation of the pcic driver (needs
testing).Recognizer and handler for
sio.c (mostly done).Recognizer and handler for
ed.c (mostly done).Recognizer and handler for
ep.c (mostly done).User-mode recognizer and handler (partially
done).Advanced Power Management. Coordinators: &a.msmith; and
&a.phk;APM sub-driver (mostly done).IDE/ATA disk sub-driver (partially done).syscons/pcvt sub-driver.Integration with the PCMCIA/PCCARD drivers
(suspend/resume).Low priority tasksThe following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them
done anytime soon:The first 20 items are from Terry Lambert
terry@lambert.orgAbility to make BIOS calls from protected mode using V86
mode on the processor and return the results via a mapped
interrupt IPC mechanism to the protected mode caller.Drivers built into the kernel that use the BIOS call
mechanism to allow them to be independent of the actual
underlying hardware the same way that DOS is independent of
the underlying hardware. This includes NetWork and ASPI
drivers loaded in DOS prior to BSD being loaded by a
DOS-based loader program, which means potential polling,
which means DOS-not-busy interrupt generation for V86
machines by the protected mode kernel.An image format that allows tagging of such drivers data
and text areas in the default kernel executable so that that
portion of the kernel address space may be recovered at a
later time, after hardware specific protected mode drivers
have been loaded and activated. This includes separation of
BIOS based drivers from each other, since it is better to
run with a BIOS based driver in all cases than to not run at
all.Abstraction of the bus interface mechanism. Currently,
PCMCIA, EISA, and PCI busses are assumed to be bridged from
ISA. This is not something which should be assumed.A configuration manager that knows about PNP events,
including power management events, insertion, extraction,
and bus (PNP ISA and PCMCIA bridging chips) vs. card level
event management.A topological sort mechanism for assigning reassignable
addresses that do not collide with other reassignable and
non-reassignable device space resource usage by fixed
devices.A registration based mechanism for hardware services
registration. Specifically, a device centric registration
mechanism for timer and sound and other system critical
service providers. Consider Timer2 and Timer0 and speaker
services as one example of a single monolithic service
provider.A kernel exported symbol space in the kernel data space
accessible by an LKM loader mechanism that does relocation
and symbol space manipulation. The intent of this interface
is to support the ability to demand load and unload kernel
modules.NetWare Server (protected mode ODI driver) loader and
subservices to allow the use of ODI card drivers supplied
with network cards. The same thing for NDIS drivers and
NetWare SCSI drivers.An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.Splitting of the console driver into abstraction layers,
both to make it easier to port and to kill the X and
ThinkPad and PS/2 mouse and LED and console switching and
bouncing NumLock problems once and for all.Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.Streams to allow the use of commercial streams drivers.Kernel multithreading (requires kernel preemption).Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).A concerted effort at support for portable computers.
This is somewhat handled by changing PCMCIA bridging rules
and power management event handling. But there are things
like detecting internal vs. external display and picking a
different screen resolution based on that fact, not spinning
down the disk if the machine is in dock, and allowing
dock-based cards to disappear without affecting the machines
ability to boot (same issue for PCMCIA).Reorganization of the source tree for multiple platform
ports.A make world that "makes the world" (rename the
current one to make regress if that is all it is good
for).A 4M (preferably smaller!) memory footprint.Smaller tasksMost of the tasks listed in the previous sections require
either a considerable investment of time or an in-depth knowledge
of the FreeBSD kernel (or both). However, there are also many
useful tasks which are suitable for "weekend hackers",
or people without programming skills.If you run FreeBSD-current and have a good Internet
connection, there is a machine current.freebsd.org which
builds a full release once a day — every now and again, try
and install the latest release from it and report any
failures in the process.Read the freebsd-bugs mailing list. There might be a
problem you can comment constructively on or with patches
you can test. Or you could even try to fix one of the
problems yourself.Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even just
completely wrong, let us know. Even better, send us a fix
(SGML is not difficult to learn, but there is no objection
to ASCII submissions).Help translate FreeBSD documentation into your native
language (if not already available) — just send an email to
&a.doc; asking if anyone is working on it. Note that you
are not committing yourself to translating every single
FreeBSD document by doing this — in fact, the documentation
most in need of translation is the installation
instructions.Read the freebsd-questions mailing list and the
newsgroup comp.unix.bsd.freebsd.misc occasionally (or even
regularly). It can be very satisfying to share your
expertise and help people solve their problems; sometimes
you may even learn something new yourself! These forums can
also be a source of ideas for things to work on.If you know of any bugfixes which have been successfully
applied to -current but have not been merged into -stable
after a decent interval (normally a couple of weeks), send
the committer a polite reminder.Move contributed software to
src/contrib in the source tree.Make sure code in src/contrib is up
to date.Look for year 2000 bugs (and fix any you find!)Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.If you have contributed any ports, send your patches
back to the original author (this will make your life easier
when they bring out the next version)Suggest further tasks for this list!How to ContributeContributions to the system generally fall into one or more of
the following 6 categories:Bug reports and general commentaryAn idea or suggestion of general
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
high volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
mailing lists for more
information about this and other mailing lists.If you find a bug or are submitting a specific change, please
report it using the send-pr1program or its
WEB-based
equivalent. Try to fill-in each field of the bug report.
Unless they exceed 65KB, include any patches directly in the
report. Consider compressing them and using
uuencode1 if they exceed 20KB. Upload very large submissions to ftp.freebsd.org:/pub/FreeBSD/incoming/.After filing a report, you should receive confirmation along
with a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to bug-followup@FreeBSD.ORG. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way.If you do not receive confirmation in a timely fashion (3 days
to a week, depending on your email connection) or are, for some
reason, unable to use the send-pr1 command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.Changes to the documentationChanges to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
send-pr as described in
Bug Reports and General
Commentary.Changes to existing source codeAn addition or change to the existing source code is a
somewhat trickier affair and depends a lot on how far out of date
you are with the current state of the core FreeBSD development.
There is a special on-going release of FreeBSD known as
“FreeBSD-current” which is made available in a variety of ways
for the convenience of developers working actively on the system.
See Staying current with FreeBSD
for more information
about getting and using FreeBSD-current.Working from older sources unfortunately means that your
changes may sometimes be too obsolete or too divergent for easy
re-integration into FreeBSD. Chances of this can be minimized
somewhat by subscribing to the &a.announce; and the &a.current;
lists, where discussions on the current state of the system take
place.Assuming that you can manage to secure fairly up-to-date
sources to base your changes on, the next step is to produce a set
of diffs to send to the FreeBSD maintainers. This is done with
the diff1 command, with the “context diff”
form being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; diff -c -r olddir newdir
would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for diff1 for more details.Once you have a set of diffs (which you may test with the
patch1 command), you should submit them for
inclusion with FreeBSD. Use the send-pr1
program as described in
Bug Reports and General
Commentary. Do not just send the diffs to
the &a.hackers; or they will get lost! We greatly appreciate your
submission (this is a volunteer project!); because we are busy, we
may not be able to address it immediately, but it will remain in
the pr database until we do.If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file and run the
uuencode1 program on it. Shar archives are
also welcome.If your change is of a potentially sensitive nature, e.g. you
are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review
first, then you should send it to &a.core; directly rather than
submitting it with send-pr1. The core
mailing list reaches a much smaller group of people who do much of
the day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to
them where it is truly necessary.Please refer to man 9 intro and
man 9 style for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.New code or major value-added packagesIn the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD, it
becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:The BSD copyright. This copyright is most preferred due
to its “no strings attached” nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial
interests who might eventually be inclined to invest
something of their own into FreeBSD.The GNU Public License, or “GPL”. This license is not
quite as popular with us due to the amount of extra effort
demanded of anyone using the code for commercial purposes,
but given the sheer quantity of GPL'd code we currently
require (compiler, assembler, text formatter, etc) it would
be silly to refuse additional contributions under this
license. Code under the GPL also goes into a different part
of the tree, that being /sys/gnu or
/usr/src/gnu, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will be
considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.To place a “BSD-style” copyright on your work, include the
following text at the very beginning of every source code file you
wish to protect, replacing the text between the
%% with the appropriate information.
Copyright (c) %%proper_years_here%%
%%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$For your convenience, a copy of this text can
be found in
/usr/share/examples/etc/bsd-style-copyright.Money, Hardware or Internet accessWe are always very happy to accept donations to further the
cause of the FreeBSD Project and, in a volunteer effort like ours,
a little can go a long way! Donations of hardware are also very
important to expanding our list of supported peripherals since we
generally lack the funds to buy such items ourselves.Donating fundsWhile the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.dg; with the goal of furthering the aims of the FreeBSD
Project and giving it a minimal corporate presence. Any and all
funds donated (as well as any profits that may eventually be
realized by FreeBSD, Inc.) will be used exclusively to further
the project's goals.Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:FreeBSD, Inc.c/o Jordan Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO
box can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to
Jordan Hubbard jkh@FreeBSD.org,
either via email or to the FreeBSD, Inc. postal address given
above.If you do not wish to be listed in our donors section, please specify this
when making your donation. Thanks!Donating hardwareDonations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the donating funds
section.Hardware for which ongoing compliance testing is
desired. We are currently trying to put together a testing
lab of all components that FreeBSD supports so that proper
regression testing can be done with each new release. We
are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a
donation, please contact &a.dg; for information on
which items are still required.Hardware currently unsupported by FreeBSD for which
you would like to see such support added. Please contact
the &a.core; before sending such items as we will need to
find a developer willing to take on the task before we can
accept delivery of new hardware.Donating Internet accessWe can always use new mirror sites for FTP, WWW or cvsup. If
you would like to be such a mirror, please contact the FreeBSD project
administrators admin@FreeBSD.ORG for more information.Donors GalleryThe FreeBSD Project is indebted to the following donors and
would like to publically thank them here!Contributors to the central server
project:The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
freefall.freebsd.org by donating the
following items:Ade
Barkah mbarkah@freebsd.org and his employer, Hemisphere Online,
donated a Pentium Pro (P6) 200Mhz
CPUASA
Computers donated a Tyan
1662 motherboard.Joe McGuckin joe@via.net
of ViaNet
Communications donated a Kingston ethernet controller.Jack
O'Neill jack@diamond.xtalwind.net donated an NCR
53C875 SCSI controller card.Ulf
Zimmermann ulf@Alameda.net of Alameda Networks
donated 128MB of memory, a
4 Gb disk drive and the
case.Direct funding:The following individuals and businesses have generously
contributed direct funding to the project:Annelise
Anderson ANDRSN@HOOVER.STANFORD.EDUMatt
Dillon dillon@best.netEpilogue
Technology CorporationSean Eric FaganDon Scott WildeGianmarco
Giovannelli gmarco@masternet.itJosef C.
Grosch joeg@truenorth.orgRobert T. MorrisChuck
Robey chuckr@freebsd.orgKenneth
P. Stox ken@stox.sa.enteract.com of Imaginary Landscape,
LLC.Dmitry S.
Kohmanyuk dk@dog.farm.orgLaser5
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.Fuki
Shuppan Publishing Co. donated a portion of
their profits from Hajimete no
FreeBSD (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.ASCII
Corp. donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.Yokogawa
Electric Corp has generously donated
significant funding to the FreeBSD project.BuffNET
+
+ Pacific
+ Solutions
+ Hardware contributors:The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:Walnut Creek CDROM for providing the Pentium P5-90
and 486/DX2-66 EISA/VL systems that are being used for
our development work, to say nothing of the network
access and other donations of hardware resources.TRW Financial Systems, Inc. provided 130 PCs, three
68 GB fileservers, twelve Ethernets, two routers and an
ATM switch for debugging the diskless code. They also
keep a couple of FreeBSD hackers alive and busy.
Thanks!Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.&a.chuck; contributed his floppy tape streamer for
experimental work.Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver.Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-)Tekram
Technologies sent one each of their DC-390,
DC-390U and DC-390F FAST and ULTRA SCSI host adapter
cards for regression testing of the NCR and AMD drivers
with their cards. They are also to be applauded for
making driver sources for free operating systems
available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD.Larry M.
Augustin contributed not only a Symbios
Sym8751S SCSI card, but also a set of data books,
including one about the forthcoming Sym53c895 chip with
Ultra-2 and LVD support, and the latest programming
manual with information on how to safely use the
advanced features of the latest Symbios SCSI chips.
Thanks a lot!Christoph
Kukulies kuku@freebsd.org donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.Special contributors:Walnut Creek
CDROM has donated almost more than we can say
(see the
history document for
more details). In particular, we would like to thank
them for the original hardware used for
freefall.FreeBSD.ORG, our primary
development machine, and for
thud.FreeBSD.ORG, a testing and
build box. We are also indebted to them for funding
various contributors over the years and providing us
with unrestricted use of their T1 connection to the
Internet.The interface
business GmbH, Dresden has been patiently
supporting &a.joerg; who has often preferred FreeBSD
work over paywork, and used to fall back to their (quite
expensive) EUnet Internet connection whenever his
private connection became too slow or flakey to work
with it...Berkeley Software
Design, Inc. has contributed their DOS
emulator code to the remaining BSD world, which is used
in the dosemu command.Derived Software ContributorsThis software was originally derived from William F. Jolitz's
386BSD release 0.1, though almost none of the original 386BSD
specific code remains. This software has been essentially
re-implemented from the 4.4BSD-Lite release provided by the Computer
Science Research Group (CSRG) at the University of California,
Berkeley and associated academic contributors.There are also portions of NetBSD and OpenBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAda T Lim ada@bsd.orgAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian T. Filipi-Martin atf3r@agate.cs.virginia.eduAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker A.C.P.M.Kalker@student.utwente.nlAlan Cox alc@cs.rice.eduAmancio Hasty ahasty@freebsd.orgAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndrew Gallatin gallatin@cs.duke.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew McRae amcrae@cisco.comAndrew Moore alm@FreeBSD.orgAndrew Stevenson andrew@ugh.net.auAndrew V. Stesin stesin@elvisti.kiev.uaAndrey Zakhvatov andy@icc.surw.chel.suAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.com
-
+
+
+ Anton Berezin tobez@plab.ku.dk
+
+
Ari Suutari ari@suutari.iki.fiBen Hutchinson benhutch@xfiles.org.ukBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBrandon Gillespie brandon@roguetrader.com&a.wlloyd;Bob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Taylor brett@peloton.physics.montana.eduBrian Clapper bmc@willscreek.com
-
+
+
+ Brian F. Feldman green@unixhelp.org
+
+
Brian Handy handy@lambic.space.lockheed.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce Gingery bgingery@gtcs.comBruce Mah bmah@ca.sandia.govCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCharles Hannum mycroft@ai.mit.eduCharles Mott cmott@srv.netChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChris Dabrowski chris@vader.orgChris G. Demetriou cgd@postgres.berkeley.eduChris Shenton cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristoph Robitschko chmr@edvz.tu-graz.ac.atChristopher T. Johnson
cjohnson@neunacht.netgsi.comChoi Jun Ho junker@jazz.snu.ac.krChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGConrad Sabatier conrads@neosoft.comCornelis van der Laan nils@guru.ims.uni-stuttgart.deCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comDai Ishijima ishijima@tri.pref.osaka.jpDan Cross tenser@spitfire.ecsel.psu.eduDaniel Baker dbaker@crash.ops.neosoft.comDaniel M. Eischen deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDanny J. Zerkel dzerkel@feephi.phofarm.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Edmondson davided@sco.comDave Rivers rivers@ponds.uucpDavid A. Bader dbader@umiacs.umd.eduDavid Dawes dawes@physics.su.OZ.AUDavid Holloway daveh@gwythaint.tamis.comDavid Leonard d@scry.dstc.edu.auDean Huxley dean@fsa.ca
-
+
+
+ Dima Sivachenko demon@gpad.ac.ru
+
+
Dirk Froemberg dirk@hal.in-berlin.deDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Yuniskis dgy@rtd.comDonald Maddox dmaddox@scsn.netDoug Ambrisko ambrisko@ambrisko.roble.comDouglas Carmichael dcarmich@mcs.comEckart “Isegrim” Hofmann
Isegrim@Wunder-Nett.orgEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Chet ejc@bazzle.comEric J. Schwertfeger eric@cybernut.comFrancis M J Hsieh mjhsieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan frankch@waru.life.nthu.edu.twFrank Maclachlan fpm@crash.cts.comFrank Nobis fn@trinity.radio-do.deFrank Volf volf@oasis.IAEhv.nlFUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jpFURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jpGary A. Browning gab10@griffcd.amdahl.comGary Kline kline@thought.orgGerard Roudier groudier@club-internet.frGilad Rom rom_glsa@ein-hashofet.co.ukGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGlenn Johnson gljohns@bellsouth.netGreg Ungerer gerg@stallion.oz.auHans Huebner hans@artcom.deHans Petter Bieker hanspb@persbraten.vgs.noHarlan Stenn Harlan.Stenn@pfcs.comHavard Eidnes Havard.Eidnes@runit.sintef.noHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jp
-
- Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
-
-
Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+
+
Hironori Ikura hikura@kaisei.orgHiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jpHolger Veit Holger.Veit@gmd.deHONDA Yasuhiro honda@kashio.info.mie-u.ac.jpHorance Chou horance@freedom.ie.cycu.edu.twHung-Chi Chu hcchu@r350.ee.ntu.edu.twIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jpIshii MasahiroIseei Suzuki issei@jp.FreeBSD.ORGItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. David Lowe lowe@saturn5.comJ. Han jtc@cygnus.comJ.T. Conklin jtc@cygnus.comJ.T. Lang keith@email.gcn.net.twJames Clark jjc@jclark.comJames da Silva jds@cs.umd.edu et alJanusz Kokot janek@gaja.ipan.lublin.plJason Thorpe thorpej@nas.nasa.govJavier Martin Rueda jmrueda@diatel.upm.esJeff Bartig jeffb@doit.wisc.eduKeff Kletsky Jeff@Wagsky.comJeffrey Wheat jeff@cetlink.netJeremy Lea reg@shale.csir.co.zaJerry Hicks jhicks@glenatl.glenayre.comJian-Da Li jdli@csie.NCTU.edu.twJim Binkley jrb@cs.pdx.eduJim Lowe james@cs.uwm.edu
-
+
+
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld/orgJoao Carlos Mendes Luis jonny@coppe.ufrj.br
+
+ Joe Abley jabley@clear.co.nz
+
+
Joe “Marcus” Clarke
marcus@miami.eduJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoel Sutton sutton@aardvark.apana.org.auJohann Tonsing jtonsing@mikom.csir.co.zaJohn Capo jc@irbs.comJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Perry perry@vishnu.alias.netJohn Polstra jdp@polstra.comJohn Rochester jr@cs.mun.caJohn Saunders john@pacer.nlc.net.auJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJosef Karthauser joe@uk.freebsd.orgJoseph Stein joes@seaport.netJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJulian Assange proff@suburbia.netJulian Jenkins kaveman@magna.com.auJulian Stacey jhs@freebsd.orgJunichi Satoh junichi@jp.freebsd.orgJunya WATANABE junya-w@remus.dti.ne.jpKapil Chowksey kchowksey@hss.hns.comKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKeith Bostic bostic@bostic.comKeith MooreKenneth Monville desmo@bandwidth.orgKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKirk McKusick mckusick@mckusick.comKiroh HARADA kiroh@kh.rim.or.jpKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.su
-
+
+
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+
+
Kurt Olsen kurto@tiny.mcs.usu.eduLars Köller Lars.Koeller@Uni-Bielefeld.DELian Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twuLucas James Lucas.James@ldjpc.apana.org.auLuigi Rizzo luigi@iet.unipi.it
-
+
+
+ Malte Lance malte.lance@gmx.net
+
+
Makoto MATSUSHITA matusita@jp.freebsd.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jp
+
+
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ Manu Iyengar iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMario Sergio Fujikawa Ferreira lioux@gns.com.brMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin BirgmeierMartti Kuparinen erakupa@kk.etx.ericsson.seMasachika ISHIZUKA ishizuka@isis.min.ntt.jpMasanori Kiriake seiken@ncs.co.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas thomas@lkg.dec.comMatt White mwhite+@CMU.EDUMatthew N. Dodd winter@jurai.netMatthew Stein matt@bdd.netMaurice Castro maurice@planet.serc.rmit.edu.auMichael Butschky butsch@computi.erols.comMichael Elbel me@FreeBSD.ORGMichael Searle searle@longacre.demon.co.ukMiguel Angel Sagreras msagre@cactus.fi.uba.arMikael Hybsch micke@dynas.seMikhail Teterin mi@aldan.ziplink.netMike McGaughey mmcg@cs.monash.edu.auMike Peck mike@binghamton.eduMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMITA Yoshio mita@jp.FreeBSD.ORGMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMotoyuki Kasahara m-hasahr@sra.co.jp
+
+
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.comNAKAMURA Kazushi nkazushi@highway.or.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNIIMI Satoshi sa2c@and.or.jpNick Sayer nsayer@quack.kfu.comNicolas Souchu Nicolas.Souchu@prism.uvsq.frNisha Talagala nisha@cs.berkeley.eduNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
+
+
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+
+
Noritaka Ishizumi graphite@jp.FreeBSD.ORGOliver Breuninger ob@seicom.NETOliver Fromme oliver.fromme@heim3.tu-clausthal.deOliver Laumann net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.com
-
+
+
+ Palle Girgensohn girgen@partitur.se
+
+
Paul Fox pgf@foxharp.boston.ma.usPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaulo Menezes paulo@isr.uc.ptPaul T. Root proot@horton.iaces.comPedro Giffuni giffunip@asme.orgPedro A M Vazquez vazquez@IQM.Unicamp.BRPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Stubbs PETERS@staidan.qld.edu.auPierre Beyssac bp@fasterix.freenix.orgPhil Maker pjm@cs.ntu.edu.auR. Kym HorsellRandall Hopper rhh@stealth.ct.picker.comRicardas Cepas rch@richard.eu.orgRichard Hwang rhwang@bigpanda.comRichard. M. Neswold rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Wiwatowski rjwiwat@adelaide.on.netRob Mallory rmallory@csusb.eduRob Shady rls@id.netRob Snow rsnow@txdirect.netRobert Sanders rsanders@mindspring.comRobert Withrow witr@rwwa.comRonald Kuehn kuehn@rz.tu-clausthal.deRoland Jesse jesse@cs.uni-magdeburg.deRuslan Shevchenko rssh@cki.ipri.kiev.uaSURANYI Peter suranyip@jks.is.tsukuba.ac.jpSamuel Lam skl@ScalableNetwork.comSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+
+ Satsuki FUJISHIMA k5@respo.or.jp
+
+
Scot W. Hetzel hetzels@westbend.netScott Blachowicz scott.blachowicz@seaslug.orgScott A. Kenney saken@rmta.ml.orgSeigou TANIMURA
tanimura@naklab.dnj.ynu.ac.jp
-
- Seiichirou Hiraoka flathill@flathill.gr.jp
-
-
Serge Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSheldon Hearn axl@iafrica.comShigeyuki FUKUSHIMA
shige@kuis.kyoto-u.ac.jpSimon Marlow simonm@dcs.gla.ac.ukSlaven Rezic (Tomic) eserte@cs.tu-berlin.deSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan “Sec” Zehl sec@42.orgStephane Legrand stephane@lituus.frStephen Farrell stephen@farrell.orgStephen J. Roznowski sjr@home.netSteve Gerakines steve2@genesis.tiac.netSteven G. Kargl
kargl@troutmask.apl.washington.eduStephen H. Samorodin samorodi@NUXU.comStuart Henderson
stuart@internationalschool.co.uk
+
+
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeu NAIKI naiki@bfd.es.hokudai.ac.jpTed Faber faber@ISI.EDUTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo Deraadt deraadt@fsa.caThomas König Thomas.Koenig@ciw.uni-karlsruhe.deÞórður Ívarsson totii@est.isTim Kientzle kientzle@netcom.comTim Wilkinson tim@sarc.city.ac.uk
+
+ Tom Hukins tom@eborcom.com
+
+
Tom Jobbins tom@tom.tjTom Samplonius tom@misery.sdf.comTorbjorn Granlund tege@matematik.su.seToshihiro Kanda candy@fct.kgc.co.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpTrefor S. trefor@flevel.co.uk
-
+
+
+ Vadim Chekan vadim@gc.lviv.ua
+
+
Ville Eerola ve@sci.fiVladimir Kushnir kushn@mail.kar.netWerner Griessl werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWilko Bulte wilko@yedi.iaf.nlWolfgang Stanglmeier wolf@kintaro.cologne.deWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshiro Mihira sanpei@yy.cs.keio.ac.jp
- Yukihiro Nakai nakai@technologist.com
+ Yukihiro Nakai nakai@iname.comYusuke Nawano azuki@azkey.orgYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nl386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse lohse@tech7.informatik.uni-hamburg.deJörg Wunsch joerg_wunsch@uriah.heep.sax.deJohn Dyson formerly
dyson@ref.tfs.comJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@freebsd.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.ORGRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
index 93ceb6062b..f29687c694 100644
--- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
@@ -1,2497 +1,2528 @@
The Cutting Edge: FreeBSD-current and FreeBSD-stableFreeBSD is under constant development between releases. For
people who want to be on the cutting edge, there are several easy
mechanisms for keeping your system in sync with the latest
developments. Be warned: the cutting edge is not for everyone! This
chapter will help you decide if you want to track the development
system, or stick with one of the released versions.Staying Current with FreeBSDContributed by &a.jkh;.What is FreeBSD-current?FreeBSD-current is, quite literally, nothing more than a daily
snapshot of the working sources for FreeBSD. These include work
in progress, experimental changes and transitional mechanisms that
may or may not be present in the next official release of the
software. While many of us compile almost daily from
FreeBSD-current sources, there are periods of time when the
sources are literally un-compilable. These problems are generally
resolved as expeditiously as possible, but whether or not
FreeBSD-current sources bring disaster or greatly desired
functionality can literally be a matter of which part of any given
24 hour period you grabbed them in!Who needs FreeBSD-current?FreeBSD-current is made generally available for 3 primary
interest groups:Members of the FreeBSD group who are actively working
on some part of the source tree and for whom keeping
“current” is an absolute requirement.Members of the FreeBSD group who are active testers,
willing to spend time working through problems in order to
ensure that FreeBSD-current remains as sane as possible.
These are also people who wish to make topical suggestions
on changes and the general direction of FreeBSD.Peripheral members of the FreeBSD (or some other)
group who merely wish to keep an eye on things and use the
current sources for reference purposes (e.g. for
reading, not running). These people
also make the occasional comment or contribute code.What is FreeBSD-current not?A fast-track to getting pre-release bits because you
heard there is some cool new feature in there and you want
to be the first on your block to have it.A quick way of getting bug fixes.In any way “officially supported” by us. We do our
best to help people genuinely in one of the 3 “legitimate”
FreeBSD-current categories, but we simply do not
have the time to provide tech support for it.
This is not because we are mean and nasty people who do not
like helping people out (we would not even be doing FreeBSD
if we were), it is literally because we cannot answer 400
messages a day and actually work on
FreeBSD! I am sure that, if given the choice between having
us answer lots of questions or continuing to improve
FreeBSD, most of you would vote for us improving it.Using FreeBSD-currentJoin the &a.current; and the &a.cvsall; . This is not
just a good idea, it is essential. If
you are not on the FreeBSD-current
- mailing list you will not see the comments that people are
+ mailing list, you will not see the comments that people are
making about the current state of the system and thus will
probably end up stumbling over a lot of problems that others
have already found and solved. Even more importantly, you
- will miss out on potentially critical information (e.g.
- “Yo, Everybody! Before you rebuild
- /usr/src, you must
- rebuild the kernel or your system will crash horribly!”).
- The cvs-all mailing list will allow you
+ will miss out on important bulletins which may be critical
+ to your system's continued health.
+
+ The cvs-all mailing list will allow you
to see the commit log entry for each change as it is made
along with any pertinent information on possible
- side-effects. To join these lists, send mail to
+ side-effects.
+
+ To join these lists, send mail to
&a.majordomo; and specify:
subscribe freebsd-current
subscribe cvs-all
in the
body of your message. Optionally, you can also say help
and Majordomo will send you full help on how to subscribe
and unsubscribe to the various other mailing lists we
support.Grab the sources from ftp.FreeBSD.ORG. You can do
this in three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile">this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
+
+
+ &prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz
+
+
+
Use ftp. The source tree for FreeBSD-current is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current We also use wu-ftpd which allows compressed/tar'd grabbing of whole trees. e.g. you see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the whole directory for you as a compressed tar file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.
-
-
-
+
If you are grabbing the sources to run, and not just
look at, then grab all of current, not
just selected portions. The reason for this is that various
parts of the source depend on updates elsewhere, and trying
to compile just a subset is almost guaranteed to get you
into trouble.
-
-
-
+
Before compiling current, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.current; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
- towards the next release.
+ towards the next release.
Be active! If you are running FreeBSD-current, we
want to know what you have to say about it, especially if
you have suggestions for enhancements or bug fixes.
Suggestions with accompanying code are received most
enthusiastically!Staying Stable with FreeBSDContributed by &a.jkh;.What is FreeBSD-stable?FreeBSD-stable is our development branch for a more low-key
and conservative set of changes intended for our next mainstream
release. Changes of an experimental or untested nature do not go
into this branch (see FreeBSD-current).Who needs FreeBSD-stable?If you are a commercial user or someone who puts maximum
stability of their FreeBSD system before all other concerns, you
should consider tracking stable. This is
especially true if you have installed the most recent release
(&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release.The stable tree endeavors, above all,
to be fully compilable and stable at all times, but we do
occasionally make mistakes (these are still active sources with
quickly-transmitted updates, after all). We also do our best to
thoroughly test fixes in current before
bringing them into stable, but sometimes
our tests fail to catch every case. If something breaks for you
in stable, please let us know
immediately! (see next section).Using FreeBSD-stableJoin the &a.stable; . This will keep you informed of
build-dependencies that may appear in
stable or any other issues requiring
special attention. Developers will also make announcements
in this mailing list when they are contemplating some
controversial fix or update, giving the users a chance to
respond if they have any issues to raise concerning the
- proposed change. To join this list, send mail to
- &a.majordomo; and say:
+ proposed change.
+
+ The cvs-all mailing list will allow you
+ to see the commit log entry for each change as it is made
+ along with any pertinent information on possible
+ side-effects.
+
+ To join these lists, send mail to
+ &a.majordomo; and specify:
-subscribe freebsd-stable In the body of your
- message. Optionally, you can also say help and Majordomo
- will send you full help on how to subscribe and unsubscribe
- to the various other mailing lists we support.
+subscribe freebsd-stable
+subscribe cvs-all
+
+ in the
+ body of your message. Optionally, you can also say help
+ and Majordomo will send you full help on how to subscribe
+ and unsubscribe to the various other mailing lists we
+ support.
If you are installing a new system and want it to be as stable
as possible, you can simply grab the latest dated branch snapshot
from ftp://releng22.freebsd.org/pub/FreeBSD/ and install it like any other release.If you are already running a previous release of 2.2 and wish
to upgrade via sources then you can easily do so from ftp.FreeBSD.ORG. This can be done in one of
three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type;&prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgzUse ftp. The source tree for FreeBSD-stable is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stableWe also use wu-ftpd which allows
compressed/tar'd grabbing of whole trees. e.g. you
see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the
whole directory for you as a compressed tar
file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.Before compiling stable, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.stable; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
towards the next release.Synchronizing Source Trees over the InternetContributed by &a.jkh;.There are various ways of using an Internet (or email)
connection to stay up-to-date with any given area of the FreeBSD
project sources, or all areas, depending on what interests you. The
primary services we offer are Anonymous
CVS, CVSup, and
CTM.Anonymous CVS and CVSup use the
pull model of updating sources. In the case of
CVSup the user (or a cron
script) invokes the cvsup program, and
it interacts with a cvsupd server
somewhere to bring your files up to date. The updates you receive
are up-to-the-minute and you get them when, and only when, you want
them. You can easily restrict your updates to the specific files or
directories that are of interest to you. Updates are generated on
the fly by the server, according to what you have and what you want
to have. Anonymous CVS is quite a bit more simplistic
than CVSup in that it's just an extension to
CVS which allows it to pull changes
directly from a remote CVS
repository. CVSup can do this far more
efficiently, but Anonymous CVS is easier to
use.CTM, on the other hand, does not
interactively compare the sources you have with those on the master
archive or otherwise pull them across.. Instead, a script which identifies changes in files since
its previous run is executed several times a day on the master CTM
machine,
any detected changes being compressed, stamped with a
sequence-number and encoded for transmission over email (in printable
ASCII only). Once received, these “CTM deltas” can then be handed
to the ctm_rmail1 utility which will automatically decode, verify
and apply the changes to the user's copy of the sources. This
process is far more efficient than CVSup, and places less strain on
our server resources since it is a push rather
than a pull model.There are other trade-offs, of course. If you inadvertently
wipe out portions of your archive, CVSup will detect and rebuild the
damaged portions for you. CTM won't do this, and if you wipe some
portion of your source tree out (and don't have it backed up) then
you will have to start from scratch (from the most recent CVS “base
delta”) and rebuild it all with CTM or, with anoncvs, simply
delete the bad bits and resync.For more information on Anonymous CVS, CTM, and CVSup, please see one of the
following sections:Anonymous CVSContributed by &a.jkh;IntroductionAnonymous CVS (or, as it is otherwise known,
anoncvs) is a feature provided by the CVS
utilities bundled with FreeBSD for synchronizing with a remote CVS
repository. Among other things, it allows users of FreeBSD to
perform, with no special privileges, read-only CVS operations
against one of the FreeBSD project's official anoncvs servers. To
use it, one simply sets the CVSROOT environment
variable to point at the appropriate anoncvs server and then uses
the cvs1 command to access it like any local
repository.While it can also be said that the CVSup and anoncvs
services both perform essentially the same function, there are
various trade-offs which can influence the user's choice of
synchronization methods. In a nutshell,
CVSup is much more efficient in its
usage of network resources and is by far the most technically
sophisticated of the two, but at a price. To use
CVSup, a special client must first be
installed and configured before any bits can be grabbed, and then
only in the fairly large chunks which
CVSup calls
collections.Anoncvs, by contrast, can be used
to examine anything from an individual file to a specific program
(like ls or grep) by
referencing the CVS module name. Of course,
anoncvs is also only good for read-only
operations on the CVS repository, so if it's your intention to
support local development in one repository shared with the
FreeBSD project bits then CVSup is
really your only option.Using Anonymous CVSConfiguring cvs1 to use an Anonymous CVS repository is a simple
matter of setting the CVSROOT environment variable
to point to one of the FreeBSD project's
anoncvs servers. At the time of this writing,
the following servers are available:USA:
anoncvs@anoncvs.freebsd.org:/cvsSince CVS allows one to “check out” virtually any
version of the FreeBSD sources that ever existed (or, in some
cases, will exist :), you need to be familiar with
the revision () flag to cvs1 and what some of the permissible values for it in
the FreeBSD Project repository are.There are two kinds of tags, revision tags and branch tags. A
revision tag refers to a specific revision. Its meaning stays the
same from day to day. A branch tag, on the other hand, refers to
the latest revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific revision,
it may mean something different tomorrow than it means
today.Here are the branch tags that users might be interested
in:HEADSymbolic name for the main line, or FreeBSD-current.
Also the default when no revision is
specified.
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
RELENG_2_2The line of development for FreeBSD-2.2.x, also known as
- FreeBSD-stable. Not valid for the ports collection.
+ 2.2-stable. Not valid for the ports collection.
RELENG_2_1_0The line of development for FreeBSD-2.1.x - this branch
is largely obsolete. Not valid for the ports
collection.Here are the revision tags that users might be interested
in:RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports
collection.RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports
collection.RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports
collection.RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports
collection.RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports
collection.RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports
collection.RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports
collection.RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports
collection.RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports
collection.RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports
collection.When you specify a branch tag, you normally receive the latest
versions of the files on that line of development. If you wish to
receive some past version, you can do so by specifying a date with
the flag. See the cvs1 man page for more details.ExamplesWhile it really is recommended that you read the manual page
for cvs1 thoroughly before doing
anything, here are some quick examples which essentially show how
to use Anonymous CVS:Checking out something from -current (ls1) and deleting it
again:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co ls
&prompt.user; cvs release -d lsChecking out the version of ls(1) in the 2.2-stable
branch:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co -rRELENG_2_2 ls
&prompt.user; cvs release -d lsCreating a list of changes (as unidiffs) to ls1 between FreeBSD 2.2.2
and FreeBSD 2.2.6:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE lsFinding out what other module names can be used:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co modules
&prompt.user; more modules/modules
&prompt.user; cvs release -d modulesOther ResourcesThe following additional resources may be helpful in learning
CVS:CVS Tutorial from Cal Poly.Cyclic
Software, commercial maintainers of CVS.CVSWeb
is the FreeBSD Project web interface for CVS.CTMContributed by &a.phk;. Updated
19-October-1997.CTM is a method for keeping a remote
directory tree in sync with a central one. It has been developed
for usage with FreeBSD's source trees, though other people may
find it useful for other purposes as time goes by. Little, if
any, documentation currently exists at this time on the process of
creating deltas, so talk to &a.phk; for more information should
you wish to use CTM for other things.Why should I use CTM?CTM will give you a local copy of the
FreeBSD source trees. There are a number of “flavors” of the
tree available. Whether you wish to track the entire cvs tree or
just one of the branches, CTM can provide you
the information. If you are an active developer on FreeBSD, but
have lousy or non-existent TCP/IP connectivity, or simply wish
to have the changes automatically sent to you,
CTM was made for you. You will need to obtain
up to three deltas per day for the most active branches.
However, you should consider having them sent by automatic
email. The sizes of the updates are always kept as small as
possible. This is typically less than 5K, with an occasional
(one in ten) being 10-50K and every now and then a biggie of
100K+ or more coming around.You will also need to make yourself aware of the various
caveats related to working directly from the development
sources rather than a pre-packaged release. This is particularly
true if you choose the “current” sources. It is recommended
that you read Staying current
with
FreeBSD.What do I need to use CTM?You will need two things: The CTM
program and the initial deltas to feed it (to get up to
“current” levels).The CTM program has been part of FreeBSD
ever since version 2.0 was released, and lives in
/usr/src/usr.sbin/CTM if
you have a copy of the source online.If you are running a pre-2.0 version of FreeBSD, you can
fetch the current CTM sources directly
from:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctmThe “deltas” you feed CTM can be had
two ways, FTP or e-mail. If you have general FTP access to the
Internet then the following FTP sites support access to
CTM:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTMor see section mirrors.FTP the relevant directory and fetch the
README file, starting from there.If you may wish to get your deltas via email:Send email to &a.majordomo; to subscribe to one of the
CTM distribution lists. “ctm-cvs-cur”
supports the entire cvs tree. “ctm-src-cur” supports the head
of the development branch. “ctm-src-2_2” supports the 2.2
release branch, etc. (If you do not know how to subscribe
yourself using majordomo, send a message first containing the
word help — it will send you back usage
instructions.)When you begin receiving your CTM updates
in the mail, you may use the ctm_rmail program
to unpack and apply them. You can actually use the
ctm_rmail program directly from a entry in
/etc/aliases if you want to have the
process run in a fully automated fashion. Check the
ctm_rmail man page for more details.No matter what method you use to get the
CTM deltas, you should subscribe to the
ctm-announce@FreeBSD.ORG mailing list. In the
future, this will be the only place where announcements
concerning the operations of the CTM system
will be posted. Send an email to &a.majordomo; with a single
line of subscribe
ctm-announce to get added to the list.Starting off with CTM for the first
timeBefore you can start using CTM deltas,
you will need to get a to a starting point for the deltas
produced subsequently to it.First you should determine what you already have. Everyone
can start from an “empty” directory. You must use an
initial “Empty&rdquo delta to start off your
CTM supported tree. At some point it is
intended that one of these “started” deltas be
distributed on the CD for your convenience. This does not
currently happen however.You can recognize
However, since the trees
are many tens of megabytes, you should prefer to start from
something already at hand. If you have a RELEASE CD, you can
copy or extract an initial source from it. This will save a
significant transfer of data.You can recognize these “starter” deltas by the
X appended to the number
(src-cur.3210XEmpty.gz for instance). The
designation following the X
corresponds to the origin of your initial “seed”. Empty is
an empty directory. As a rule a base transition from
Empty is produced
every 100 deltas. By the way, they are large! 25 to 30
Megabytes of gzip'ed data is
common for the XEmpty deltas.Once you've picked a base delta to start from, you will also
need all deltas with higher numbers following it.Using CTM in your daily lifeTo apply the deltas, simply say:&prompt.root; cd /where/ever/you/want/the/stuff
&prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.*CTM understands deltas which have been
put through gzip, so you do not
need to gunzip them first, this saves disk space.Unless it feels very secure about the entire process,
CTM will not touch your tree. To verify a
delta you can also use the flag and
CTM will not actually touch your tree; it
will merely verify the integrity of the delta and see if it
would apply cleanly to your current tree.There are other options to CTM as well,
see the manual pages or look in the sources for more
information.I would also be very happy if somebody could help with the
“user interface” portions, as I have realized that I cannot
make up my mind on what options should do what, how and
when...That's really all there is to it. Every time you get a new
delta, just run it through CTM to keep your
sources up to date.Do not remove the deltas if they are hard to download again.
You just might want to keep them around in case something bad
happens. Even if you only have floppy disks, consider using
fdwrite to make a copy.Keeping your local changesAs a developer one would like to experiment with and change
files in the source tree. CTM supports local modifications in a
limited way: before checking for the presence of a file
foo, it first looks for
foo.ctm. If this file exists, CTM will
operate on it instead of foo.This behaviour gives us a simple way to maintain local
changes: simply copy the files you plan to modify to the
corresponding file names with a .ctm
suffix. Then you can freely hack the code, while CTM keeps the
.ctm file up-to-date.Other interesting CTM optionsFinding out exactly what would be touched by an
updateYou can determine the list of changes that CTM will make
on your source repository using the
option to CTM.This is useful if you would like to keep logs of the
changes, pre- or post- process the modified files in any
manner, or just are feeling a tad paranoid :-).Making backups before updatingSometimes you may want to backup all the files that would
be changed by a CTM update.Specifying the option
causes CTM to backup all files that would be touched by a
given CTM delta to backup-file.Restricting the files touched by an updateSometimes you would be interested in restricting the scope
of a given CTM update, or may be interested in extracting just
a few files from a sequence of deltas.You can control the list of files that CTM would operate
on by specifying filtering regular expressions using the
and
options.For example, to extract an up-to-date copy of
lib/libc/Makefile from your collection of
saved CTM deltas, run the commands:&prompt.root; cd /where/ever/you/want/to/extract/it/
&prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*For every file specified in a CTM delta, the
and options
are applied in the order given on the command line. The file
is processed by CTM only if it is marked as eligible after all
the and
options are applied to it.Future plans for CTMTons of them:Use some kind of authentication into the CTM system,
so as to allow detection of spoofed CTM updates.Clean up the options to CTM, they
became confusing and counter intuitive.The bad news is that I am very busy, so any help in doing
this will be most welcome. And do not forget to tell me what
you want also...Miscellaneous stuffAll the “DES infected” (e.g. export controlled) source is
not included. You will get the “international” version only.
If sufficient interest appears, we will set up a sec-cur sequence too. There is a
sequence of deltas for the ports
collection too, but interest has not been all that high yet.
Tell me if you want an email list for that too and we will
consider setting it up.Thanks!&a.bde;for his pointed pen and invaluable comments.&a.sos;for patience.Stephen McKaywrote ctm_[rs]mail,
much appreciated.&a.jkh;for being so stubborn that I had to make it
better.All the usersI hope you like it...CVSupContributed by &a.jdp;.IntroductionCVSup is a software package for distributing and updating
source trees from a master CVS repository on a remote server
host. The FreeBSD sources are maintained in a CVS repository on
a central development machine in California. With CVSup,
FreeBSD users can easily keep their own source trees up to
date.CVSup uses the so-called pull model of
updating. Under the pull model, each client asks the server for
updates, if and when they are wanted. The server waits
passively for update requests from its clients. Thus all
updates are instigated by the client. The server never sends
unsolicited updates. Users must either run the CVSup client
manually to get an update, or they must set up a cron job to run
it automatically on a regular basis.The term CVSup, capitalized just so, refers to the entire
software package. Its main components are the client cvsup
which runs on each user's machine, and the server cvsupd which
runs at each of the FreeBSD mirror sites.As you read the FreeBSD documentation and mailing lists, you
may see references to sup. Sup was the
predecessor of CVSup, and it served a similar purpose. CVSup is
in used in much the same way as sup and, in fact, uses
configuration files which are backward-compatible with sup's.
Sup is no longer used in the FreeBSD project, because CVSup is
both faster and more flexible.InstallationThe easiest way to install CVSup if you are running FreeBSD
2.2 or later is to use either the port from the FreeBSD ports collection or the corresponding binary package, depending on whether you prefer to roll your own or not.If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately
cannot use the binary package versions due to the fact that it
requires a version of the C library that does not yet exist in
FreeBSD-2.1.{6,7}. You can easily use the port, however, just as with FreeBSD 2.2. Simply unpack the tar file, cd to the cvsup subdirectory and type make install.Because CVSup is written in Modula-3, both the package and the port require that the Modula-3 runtime libraries be installed. These are available as the lang/modula-3-lib port and the lang/modula-3-lib-3.6 package. If you follow the same directions as for cvsup, these libraries will be compiled and/or installed automatically when you install the CVSup port or package.The Modula-3 libraries are rather large, and fetching and
compiling them is not an instantaneous process. For that
reason, a third option is provided. You can get
statically linked FreeBSD executables for
CVSup from either the USA distribution site:ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup-bin-15.4.2.tar.gz (client including GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.4.2.tar.gz (client without GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupd-bin-15.4.2.tar.gz (server).as well as from the many FreeBSD FTP mirror sites around the
world.ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-15.3.tar.gz (client including GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.3.tar.gz (client without GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-15.3.tar.gz (server).Most users will need only the client. These executables are
entirely self-contained, and they will run on any version of
FreeBSD from FreeBSD-2.1.0 to FreeBSD-current.In summary, your options for installing CVSup are:FreeBSD-2.2 or later: static binary, port,
or packageFreeBSD-2.1.6, 2.1.7: static binary or
portFreeBSD-2.1.5 or earlier: static binaryConfigurationCVSup's operation is controlled by a configuration file
called the supfile. Beginning with
FreeBSD-2.2, there are some sample supfiles
in the directory /usr/share/examples/cvsup. These examples are also available from ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ if you are on a pre-2.2 system.The information in a supfile answers
the following questions for cvsup:Which files
do you want to receive?Which
versions of them do you want?Where do you
want to get them from?Where do you
want to put them on your own machine?Where do
you want to put your status files?In the following sections, we will construct a typical
supfile by answering each of these
questions in turn. First, we describe the overall structure of
a supfile.A supfile is a text file. Comments
begin with # and extend to the end of the line. Lines that
are blank and lines that contain only comments are
ignored.Each remaining line describes a set of files that the user
wishes to receive. The line begins with the name of a
“collection”, a logical grouping of files defined by the server.
The name of the collection tells the server which files you
want. After the collection name come zero or more fields,
separated by white space. These fields answer the questions
listed above. There are two types of fields: flag fields and
value fields. A flag field consists of a keyword standing
alone, e.g., delete or compress. A value field also begins
with a keyword, but the keyword is followed without intervening
white space by = and a second word. For example,
release=cvs is a value field.A supfile typically specifies more than
one collection to receive. One way to structure a
supfile is to specify all of the relevant
fields explicitly for each collection. However, that tends to
make the supfile lines quite long, and it
is inconvenient because most fields are the same for all of the
collections in a supfile. CVSup provides a
defaulting mechanism to avoid these problems. Lines beginning
with the special pseudo-collection name *default can be used
to set flags and values which will be used as defaults for the
subsequent collections in the supfile. A
default value can be overridden for an individual collection, by
specifying a different value with the collection itself.
Defaults can also be changed or augmented in mid-supfile by
additional *default lines.With this background, we will now proceed to construct a
supfile for receiving and updating the main
source tree of FreeBSD-current.Which files do you want to receive?The files available via CVSup are organized into named
groups called “collections”. The collections that are
available are described here. In this example, we wish to receive the
entire main source tree for the FreeBSD system. There is
a single large collection src-all which will give us all
of that, except the export-controlled cryptography
support. Let us assume for this example that we are in
the USA or Canada. Then we can get the cryptography code
with one additional collection, cvs-crypto. As a first
step toward constructing our supfile,
we simply list these collections, one per line:
src-all
cvs-cryptoWhich version(s) of them do you want?With CVSup, you can receive virtually any version of
the sources that ever existed. That is possible because
the cvsupd server works directly from the CVS repository,
which contains all of the versions. You specify which one
of them you want using the tag= and value
fields.Be very
careful to specify any tag= fields correctly. Some tags
are valid only for certain collections of files. If you
specify an incorrect or misspelled tag, CVSup will delete
files which you probably do not want deleted. In
particular, use only
tag=. for the ports-*
collections.The tag= field names a symbolic tag in the
repository. There are two kinds of tags, revision tags
and branch tags. A revision tag refers to a specific
revision. Its meaning stays the same from day to day. A
branch tag, on the other hand, refers to the latest
revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific
revision, it may mean something different tomorrow than it
means today.Here are the branch tags that users might be
interested in:tag=.The main line of development, also known as
FreeBSD-current.The . is not punctuation; it is the name
of the tag. Valid for all collections.
-
- tag=RELENG_2_2
-
-
- The line of development for FreeBSD-2.2.x,
- also known as FreeBSD-stable. Not valid for the
- ports-* collections.
-
-
-
-
+
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
+
+ RELENG_2_2
+
+
+ The line of development for FreeBSD-2.2.x, also known as
+ 2.2-stable. Not valid for the ports collection.
+
+
+
tag=RELENG_2_1_0The line of development for FreeBSD-2.1.x -
this branch is largely obsolete. Not valid for the
ports-* collections.Here are the revision tags that users might be
interested in:tag=RELENG_3_0_0_RELEASEFreeBSD-3.0. Not valid for the ports-*
collections.tag=RELENG_2_2_7_RELEASEFreeBSD-2.2.7. Not valid for the ports-*
collections.tag=RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports-*
collections.tag=RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports-*
collections.tag=RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports-*
collections.tag=RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports-*
collections.tag=RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports-*
collections.tag=RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports-*
collections.tag=RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports-*
collections.tag=RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports-*
collections.tag=RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports-*
collections.tag=RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports-*
collections.Be very
careful to type the tag name exactly as shown. CVSup
cannot distinguish between valid and invalid tags. If you
misspell the tag, CVSup will behave as though you had
specified a valid tag which happens to refer to no files
at all. It will delete your existing sources in that
case.When you specify a branch tag, you normally receive
the latest versions of the files on that line of
development. If you wish to receive some past version,
you can do so by specifying a date with the value
field. The cvsup1 manual page explains how to do
that.For our example, we wish to receive FreeBSD-current.
We add this line at the beginning of our
supfile:
*default tag=.There is an important special case that comes into
play if you specify neither a tag=
field nor a date=
field. In that case, you receive the actual RCS files
directly from the server's CVS repository, rather than
receiving a particular version. Developers generally
prefer this mode of operation. By maintaining a copy of
the repository itself on their systems, they gain the
ability to browse the revision histories and examine past
versions of files. This gain is achieved at a large cost
in terms of disk space, however.Where do you want to get them from?We use the host= field to tell cvsup where to obtain
its updates. Any of the CVSup
mirror sites will do, though you should try to select
one that's near to you. In this example, we'll use the
primary FreeBSD distribution site,
cvsup.FreeBSD.org:
*default host=cvsup.FreeBSD.orgOn any particular run of cvsup, you can override this
setting on the command line, with .Where do you want to put them on your own
machine?The prefix= field tells cvsup where to put the files
it receives. In this example, we will put the source files
directly into our main source tree, /usr/src. The src
directory is already implicit in the collections we have
chosen to receive, so this is the correct
specification:
*default prefix=/usrWhere should cvsup maintain its status files?The cvsup client maintains certain status files in
what is called the “base” directory. These files help
CVSup to work more efficiently, by keeping track of which
updates you have already received. We will use the
standard base directory, /usr/local/etc/cvsup:
*default base=/usr/local/etc/cvsupThis setting is used by default if it is not specified
in the supfile, so we actually do not
need the above line.If your base directory does not already exist, now
would be a good time to create it. The cvsup client will
refuse to run if the base directory does not exist.Miscellaneous supfile settings:There is one more line of boiler plate that normally
needs to be present in the supfile:
*default release=cvs delete use-rel-suffix compressrelease=cvs indicates that the server should get its
information out of the main FreeBSD CVS repository. This
is virtually always the case, but there are other
possibilities which are beyond the scope of this
discussion.delete gives CVSup permission to delete files. You
should always specify this, so that CVSup can keep your
source tree fully up to date. CVSup is careful to delete
only those files for which it is responsible. Any extra
files you happen to have will be left strictly
alone.use-rel-suffix is ... arcane. If you really want to
know about it, see the cvsup1 manual page. Otherwise,
just specify it and do not worry about it.compress enables the use of gzip-style compression
on the communication channel. If your network link is T1
speed or faster, you probably should not use compression.
Otherwise, it helps substantially.Putting it all together:Here is the entire supfile for
our example:
*default tag=.
*default host=cvsup.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress
src-all
cvs-cryptoRunning CVSupYou are now ready to try an update. The command line for
doing this is quite simple:&prompt.root; cvsup supfilewhere supfile is of course the name of the supfile you
have just created. Assuming you are running under X11, cvsup
will display a GUI window with some buttons to do the usual
things. Press the “go” button, and watch it run.Since you are updating your actual /usr/src tree in this
example, you will need to run the program as root so that cvsup
has the permissions it needs to update your files. Having just
created your configuration file, and having never used this
program before, that might understandably make you nervous.
There is an easy way to do a trial run without touching your
precious files. Just create an empty directory somewhere
convenient, and name it as an extra argument on the command
line:&prompt.root; mkdir /var/tmp/dest
&prompt.root; cvsup supfile /var/tmp/destThe directory you specify will be used as the destination
directory for all file updates. CVSup will examine your usual
files in /usr/src, but it will not modify
or delete any of them. Any file updates will instead land in
/var/tmp/dest/usr/src. CVSup will also
leave its base directory status files untouched when run this
way. The new versions of those files will be written into the
specified directory. As long as you have read access to
/usr/src, you do not even need to be root
to perform this kind of trial run.If you are not running X11 or if you just do not like GUIs,
you should add a couple of options to the command line when you
run cvsup:&prompt.root; cvsup -g -L 2 supfileThe tells cvsup not to use its GUI. This is automatic
if you are not running X11, but otherwise you have to specify
it.The tells cvsup to print out the details of all the
file updates it is doing. There are three levels of verbosity,
from to . The default is 0, which means total
silence except for error messages.There are plenty of other options available. For a brief
list of them, type cvsup -H. For more detailed descriptions,
see the manual page.Once you are satisfied with the way updates are working, you
can arrange for regular runs of cvsup using cron8. Obviously,
you should not let cvsup use its GUI when running it from
cron.CVSup File CollectionsThe file collections available via CVSup are organized
hierarchically. There are a few large collections, and they are
divided into smaller sub-collections. Receiving a large
collection is equivalent to receiving each of its
sub-collections. The hierarchical relationships among
collections are reflected by the use of indentation in the list
below.The most commonly used collections are src-all, cvs-crypto, and ports-all. The other collections are used
only by small groups of people for specialized purposes, and
some mirror sites may not carry all of them.cvs-all
release=cvsThe main FreeBSD CVS repository, excluding the
export-restricted cryptography code.distrib
release=cvsFiles related to the distribution and
mirroring of FreeBSD.doc-all
release=cvsSources for the FreeBSD handbook and other
documentation.ports-all
release=cvsThe FreeBSD ports collection.ports-archivers
release=cvsArchiving tools.ports-astro
release=cvsAstronomical ports.ports-audio
release=cvsSound support.ports-base
release=cvsMiscellaneous files at the top of
/usr/ports.ports-benchmarks
release=cvsBenchmarks.ports-biology
release=cvsBiology.ports-cad
release=cvsComputer aided design tools.ports-chinese
release=cvsChinese language support.ports-comms
release=cvsCommunication software.ports-converters
release=cvscharacter code converters.ports-databases
release=cvsDatabases.ports-deskutils
release=cvsThings that used to be on the desktop before
computers were invented.ports-devel
release=cvsDevelopment utilities.ports-editors
release=cvsEditors.ports-emulators
release=cvsEmulators for other operating
systems.ports-games
release=cvsGames.ports-german
release=cvsGerman language support.ports-graphics
release=cvsGraphics utilities.ports-japanese
release=cvsJapanese language support.ports-korean
release=cvsKorean language support.ports-lang
release=cvsProgramming languages.ports-mail
release=cvsMail software.ports-math
release=cvsNumerical computation
software.ports-mbone
release=cvsMBone applications.ports-misc
release=cvsMiscellaneous utilities.ports-net
release=cvsNetworking software.ports-news
release=cvsUSENET news software.ports-plan9
release=cvsVarious programs from Plan9.ports-print
release=cvsPrinting software.ports-russian
release=cvsRussian language support.ports-security
release=cvsSecurity utilities.ports-shells
release=cvsCommand line shells.ports-sysutils
release=cvsSystem utilities.ports-textproc
release=cvstext processing utilities (does not
include desktop publishing).ports-vietnamese
release=cvsVietnamese language support.ports-www
release=cvsSoftware related to the World Wide
Web.ports-x11
release=cvsPorts to support the X window
system.ports-x11-clocks
release=cvsX11 clocks.ports-x11-fm
release=cvsX11 file managers.ports-x11-fonts
release=cvsX11 fonts and font utilities.ports-x11-toolkits
release=cvsX11 toolkits.ports-x11-wmX11 window managers.src-all
release=cvsThe main FreeBSD sources, excluding the
export-restricted cryptography code.src-base
release=cvsMiscellaneous files at the top of
/usr/src.src-bin
release=cvsUser utilities that may be needed in
single-user mode
(/usr/src/bin).src-contrib
release=cvsUtilities and libraries from outside
the FreeBSD project, used relatively
unmodified
(/usr/src/contrib).src-etc
release=cvsSystem configuration files
(/usr/src/etc).src-games
release=cvsGames
(/usr/src/games).src-gnu
release=cvsUtilities covered by the GNU Public
License
(/usr/src/gnu).src-include
release=cvsHeader files
(/usr/src/include).src-kerberosIV
release=cvsKerberosIV security package
(/usr/src/kerberosIV).src-lib
release=cvsLibraries
(/usr/src/lib).src-libexec
release=cvsSystem programs normally executed by
other programs
(/usr/src/libexec).src-release
release=cvsFiles required to produce a FreeBSD
release
(/usr/src/release).src-sbin
release=cvsSystem utilities for single-user
mode
(/usr/src/sbin).src-share
release=cvsFiles that can be shared across
multiple systems
(/usr/src/share).src-sys
release=cvsThe kernel
(/usr/src/sys).src-tools
release=cvsVarious tools for the maintenance of
FreeBSD
(/usr/src/tools).src-usrbin
release=cvsUser utilities
(/usr/src/usr.bin).src-usrsbin
release=cvsSystem utilities
(/usr/src/usr.sbin).www
release=cvsThe sources for the World Wide Web
data.cvs-crypto
release=cvsThe export-restricted cryptography code.src-crypto
release=cvsExport-restricted utilities and libraries
from outside the FreeBSD project, used
relatively unmodified
(/usr/src/crypto).src-eBones
release=cvsKerberos and DES
(/usr/src/eBones).src-secure
release=cvsDES
(/usr/src/secure).distrib
release=selfThe CVSup server's own configuration files. Used by
CVSup mirror sites.gnats
release=currentThe GNATS bug-tracking database.mail-archive
release=currentFreeBSD mailing list archive.www
release=currentThe installed World Wide Web data. Used by WWW
mirror sites.Announcements, Questions, and Bug ReportsMost FreeBSD-related discussion of CVSup takes place on the
&a.hackers;. New versions of the software are announced there,
as well as on the &a.announce;.Questions and bug reports should be addressed to the author
of the program at cvsup-bugs@polstra.com.Using make world to rebuild your
systemContributed by &a.nik;.Once you have synchronised your local source tree against a
particular version of FreeBSD (stable,
current and so on) you must then use
the source tree to rebuild the system.Currently, the best source of information on how to do that is a
tutorial available from http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html.A successor to this tutorial will be integrated into the
handbook.
diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
index c1fcd45ce2..56e4bc2172 100644
--- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
@@ -1,1143 +1,1289 @@
Resources on the InternetContributed by &a.jkh;.The rapid pace of FreeBSD progress makes print media impractical
as a means of following the latest developments. Electronic resources
are the best, if not often the only, way stay informed of the latest
advances. Since FreeBSD is a volunteer effort, the user community
itself also generally serves as a “technical support department” of
sorts, with electronic mail and USENET news being the most effective
way of reaching that community.The most important points of contact with the FreeBSD user
community are outlined below. If you are aware of other resources not
mentioned here, please send them to the &a.doc;so that they may also
be included.Mailing listsThough many of the FreeBSD development members read USENET, we
cannot always guarantee that we will get to your questions in a
timely fashion (or at all) if you post them only to one of the
comp.unix.bsd.freebsd.* groups. By addressing your questions to the
appropriate mailing list you will reach both us and a concentrated
FreeBSD audience, invariably assuring a better (or at least faster)
response.The charters for the various lists are given at the bottom of
this document. Please read the charter before
joining or sending mail to any list. Most of our list
subscribers now receive many hundreds of FreeBSD related messages
every day, and by setting down charters and rules for proper use we
are striving to keep the signal-to-noise ratio of the lists high.
To do less would see the mailing lists ultimately fail as an
effective communications medium for the project.Archives are kept for all of the mailing lists and can be
searched using the FreeBSD World Wide Web
server. The keyword searchable archive offers an
excellent way of finding answers to frequently asked questions and
should be consulted before posting a question.List summaryGeneral lists: The following are
general lists which anyone is free (and encouraged) to join:ListPurposefreebsd-advocacyFreeBSD Evangelismfreebsd-announceImportant events and project milestonesfreebsd-bugsBug reportsfreebsd-chatNon-technical items related to the FreeBSD
communityfreebsd-currentDiscussion concerning the use of
FreeBSD-current
-
- freebsd-stable
- Discussion concerning the use of
- FreeBSD-stable
-
-
freebsd-ispIssues for Internet Service Providers using
FreeBSDfreebsd-jobsFreeBSD employment and consulting
opportunitiesfreebsd-newbiesNew FreeBSD users activities and discussionsfreebsd-questions
- User questions
+ User questions and technical support
+
+
+ freebsd-stable
+ Discussion concerning the use of
+ FreeBSD-stable
+
+
Technical lists: The following
lists are for technical discussion. You should read the charter
for each list carefully before joining or sending mail to one as
there are firm guidelines for their use and content.ListPurposefreebsd-afsPorting AFS to FreeBSDfreebsd-alphaPorting FreeBSD to the Alphafreebsd-doc
- The FreeBSD Documentation project
+ Creating FreeBSD related documentsfreebsd-databaseDiscussing database use and development under
FreeBSDfreebsd-emulationEmulation of other systems such as
Linux/DOS/Windowsfreebsd-fsFilesystemsfreebsd-hackersGeneral technical discussionfreebsd-hardwareGeneral discussion of hardware for running
FreeBSDfreebsd-isdnISDN developersfreebsd-javaJava developers and people porting JDKs to
FreeBSDfreebsd-mobileDiscussions about mobile computingfreebsd-mozillaPorting mozilla to FreeBSDfreebsd-netNetworking discussion and TCP/IP/source codefreebsd-platformsConcerning ports to non-Intel architecture
platformsfreebsd-portsDiscussion of the ports collectionfreebsd-scsiThe SCSI subsystemfreebsd-securitySecurity issuesfreebsd-smallUsing FreeBSD in embedded applicationsfreebsd-smpDesign discussions for [A]Symmetric
MultiProcessingfreebsd-sparcPorting FreeBSD to Sparc systemsfreebsd-tokenringSupport Token Ring in FreeBSDLimited lists: The following
lists require approval from core@FreeBSD.ORG to join,
though anyone is free to send messages to them which fall within
the scope of their charters. It is also a good idea establish a
presence in the technical lists before asking to join one of these
limited lists.ListPurposefreebsd-adminAdministrative issuesfreebsd-archArchitecture and design discussionsfreebsd-coreFreeBSD core teamfreebsd-hubsPeople running mirror sites (infrastructural
support)freebsd-installInstallation developmentfreebsd-security-notificationsSecurity notificationsfreebsd-user-groupsUser group coordinationCVS lists: The following lists
are for people interested in seeing the log messages for changes
to various areas of the source tree. They are Read-Only lists and should not have mail
sent to them.ListSource areaArea Description (source for)cvs-all/usr/srcAll changes to the tree (superset)How to subscribeAll mailing lists live on FreeBSD.ORG, so
to post to a given list you simply mail to
listname@FreeBSD.ORG. It will
then be redistributed to mailing list members world-wide.To subscribe to a list, send mail to &a.majordomo; and include
subscribe <listname> [<optional address>]
in the body of your message. For example, to
subscribe yourself to freebsd-announce, you'd do:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce
^DIf you want to subscribe yourself under a
different name, or submit a subscription request for a local
mailing list (this is more efficient if you have several
interested parties at one site, and highly appreciated by us!),
you would do something like:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce local-announce@somesite.com
^DFinally, it is also possible to unsubscribe
yourself from a list, get a list of other list members or see the
list of mailing lists again by sending other types of control
messages to majordomo. For a complete list of available commands,
do this:&prompt.user; mail majordomo@FreeBSD.ORG
help
^DAgain, we would like to request that you keep
discussion in the technical mailing lists on a technical track.
If you are only interested in the “high points” then it is
suggested that you join freebsd-announce, which is intended only
for infrequent traffic.List chartersAllFreeBSD mailing lists have
certain basic rules which must be adhered to by anyone using them.
Failure to comply with these guidelines will result in two (2)
written warnings from the FreeBSD Postmaster postmaster@freebsd.org, after
which, on a third offense, the poster will removed from all
FreeBSD mailing lists and filtered from further posting to them.
We regret that such rules and measures are necessary at all, but
today's Internet is a pretty harsh environment, it would seem, and
many fail to appreciate just how fragile some of its mechanisms
are.Rules of the road:The topic of any posting should adhere to the basic
charter of the list it is posted to, e.g. if the list is
about technical issues then your posting should contain
technical discussion. Ongoing irrelevant chatter or flaming
only detracts from the value of the mailing list for
everyone on it and will not be tolerated. For free-form
discussion on no particular topic, the freebsd-chat freebsd-chat@freebsd.org
mailing list is freely available and should be used
instead.No posting should be made to more than 2 mailing lists,
and only to 2 when a clear and obvious need to post to both
lists exists. For most lists, there is already a great deal
of subscriber overlap and except for the most esoteric mixes
(say "-stable & -scsi"), there really is no reason to
post to more than one list at a time. If a message is sent
to you in such a way that multiple mailing lists appear on
the Cc line then the cc line should also be trimmed before
sending it out again. You are still responsible for your own
cross-postings, no matter who the originator might have
been.Personal attacks and profanity (in the context of an
argument) are not allowed, and that includes users and
developers alike. Gross breaches of netiquette, like
excerpting or reposting private mail when permission to do
so was not and would not be forthcoming, are frowned upon
but not specifically enforced. However, there are also very few cases
where such content would fit within the charter of a list
and it would therefore probably rate a warning (or ban) on
that basis alone.Advertising of non-FreeBSD related products or services
is strictly prohibited and will result in an immediate ban
if it is clear that the offender is advertising by
spam.Individual list charters:FREEBSD-AFSAndrew File SystemThis list is for discussion on porting and using AFS from
CMU/TransarcFREEBSD-ADMINAdministrative issuesThis list is purely for discussion of freebsd.org
related issues and to report problems or abuse of project
resources. It is a closed list, though anyone may report
a problem (with our systems!) to it.FREEBSD-ANNOUNCEImportant events /
milestonesThis is the mailing list for people interested only
in occasional announcements of significant FreeBSD events.
This includes announcements about snapshots and other
releases. It contains announcements of new FreeBSD
capabilities. It may contain calls for volunteers etc.
This is a low volume, strictly moderated mailing
list.FREEBSD-ARCHArchitecture and design
discussionsThis is a moderated list for discussion of FreeBSD
architecture. Messages will mostly be kept technical in
nature, with (rare) exceptions for other messages the
moderator deems need to reach all the subscribers of the
list. Examples of suitable topics;How to re-vamp the build system to have several
customized builds running at the same time.What needs to be fixed with VFS to make Heidemann
layers work.How do we change the device driver interface to be
able to use the ame drivers cleanly on many buses and
architectures?How do I write a network driver?The moderator reserves the right to do minor editing
(spell-checking, grammar correction, trimming) of messages
that are posted to the list. The volume of the list will be
kept low, which may involve having to delay topics until an
active discussion has been resolved.FREEBSD-BUGSBug reportsThis is
the mailing list for reporting bugs in FreeBSD Whenever
possible, bugs should be submitted using the send-pr1
command or the WEB
interface to it.FREEBSD-CHATNon technical items related to the FreeBSD
communityThis list contains the
overflow from the other lists about non-technical, social
information. It includes discussion about whether Jordan
looks like a toon ferret or not, whether or not to type in
capitals, who is drinking too much coffee, where the best
beer is brewed, who is brewing beer in their basement, and
so on. Occasional announcements of important events (such
as upcoming parties, weddings, births, new jobs, etc) can
be made to the technical lists, but the follow ups should
be directed to this -chat list.FREEBSD-COREFreeBSD core teamThis is an internal mailing list for use by the core
members. Messages can be sent to it when a serious
FreeBSD-related matter requires arbitration or high-level
scrutiny.FREEBSD-CURRENTDiscussions about the use of
FreeBSD-currentThis is the
mailing list for users of freebsd-current. It includes
warnings about new features coming out in -current that
will affect the users, and instructions on steps that must
be taken to remain -current. Anyone running “current” must
subscribe to this list. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-CURRENT-DIGESTDiscussions about the use of
FreeBSD-currentThis is the
digest version of the freebsd-current mailing list. The
digest consists of all messages sent to freebsd-current
bundled together and mailed out as a single message. The
average digest size is about 40kB. This list is Read-Only and should not be posted
to.
- FREEBSD-STABLE
-
-
- Discussions about the use of
- FreeBSD-stable
-
- This is the
- mailing list for users of freebsd-stable. It includes
- warnings about new features coming out in -stable that
- will affect the users, and instructions on steps that must
- be taken to remain -stable. Anyone running “stable”
- should subscribe to this list. This is a technical mailing
- list for which strictly technical content is
- expected.
-
-
-
FREEBSD-DOCDocumentation project
- This mailing list is for the discussion of documentation
- related issues and projects. The members of this mailing list
- are collectively referred to as “The FreeBSD
- Documentation Project”. It is an open list; feel free to
- join and contribute.
+ This mailing list is for the discussion of issues and
+ projects related to the creation of documenation for
+ FreeBSD. The members of this mailing list are collectively
+ referred to as “The FreeBSD Documentation
+ Project”. It is an open list; feel free to join and
+ contribute!FREEBSD-FSFilesystemsDiscussions concerning FreeBSD filesystems. This is a
technical mailing list for which strictly technical
content is expected.FREEBSD-ISDNISDN CommunicationsThis is the mailing list for people discussing the
development of ISDN support for FreeBSD.FREEBSD-JAVAJava Development
This is the mailing list for people discussing the
development of significant Java applications for FreeBSD
and the porting and maintenance of JDKs.FREEBSD-HACKERSTechnical discussionsThis is a forum for technical discussions related to
FreeBSD. This is the primary technical mailing list. It
is for individuals actively working on FreeBSD, to bring
up problems or discuss alternative solutions. Individuals
interested in following the technical discussion are also
welcome. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-HACKERS-DIGESTTechnical discussionsThis is the digest version of the freebsd-hackers
mailing list. The digest consists of all messages sent to
freebsd-hackers bundled together and mailed out as a
single message. The average digest size is about 40kB.
This list is Read-Only and
should not be posted to.FREEBSD-HARDWAREGeneral discussion of FreeBSD
hardwareGeneral discussion
about the types of hardware that FreeBSD runs on, various
problems and suggestions concerning what to buy or
avoid.FREEBSD-INSTALLInstallation discussionThis mailing list is for discussing FreeBSD
installation development for the future releases and is
closed.FREEBSD-ISPIssues for Internet Service
ProvidersThis mailing list is
for discussing topics relevant to Internet Service
Providers (ISPs) using FreeBSD. This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-NEWBIESNewbies activities
discussionWe cover any of the activities of newbies that are not
already dealt with elsewhere, including: independent learning
and problem solving techniques, finding and using resources
and asking for help elsewhere, how to use mailing lists and
which lists to use, general chat, making mistakes, boasting,
sharing ideas, stories, moral (but not technical) support, and
taking an active part in the FreeBSD community. We take our
problems and support questions to freebsd-questions, and use
freebsd-newbies to meet others who are doing the same things
that we do as newbies.FREEBSD-PLATFORMSPorting to Non-Intel
platformsCross-platform freebsd
issues, general discussion and proposals for non-Intel
FreeBSD ports. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-PORTSDiscussion of
“ports”Discussions concerning FreeBSD's “ports collection”
(/usr/ports), proposed ports, modifications to ports
collection infrastructure and general coordination
efforts. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-QUESTIONSUser questionsThis
is the mailing list for questions about FreeBSD. You
should not send “how to” questions to the technical lists
unless you consider the question to be pretty
technical.FREEBSD-QUESTIONS-DIGESTUser questionsThis
is the digest version of the freebsd-questions mailing
list. The digest consists of all messages sent to
freebsd-questions bundled together and mailed out as a
single message. The average digest size is about
40kB.FREEBSD-SCSISCSI subsystemThis
is the mailing list for people working on the scsi
subsystem for FreeBSD. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-SECURITYSecurity issuesFreeBSD computer security issues (DES, Kerberos, known
security holes and fixes, etc). This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-SECURITY-NOTIFICATIONSSecurity Notifications Notifications of FreeBSD security problems and fixes.
This is not a discussion list. The discussion list is
FreeBSD-security.FREEBSD-SMALLThis list discusses topics related to unsually small and
embedded FreeBSD installations. This is a technical mailing
list for which strictly technical content is expected.
- FREEBSD-USER-GROUPS
+ FREEBSD-STABLE
+
+
+ Discussions about the use of
+ FreeBSD-stable
+
+ This is the
+ mailing list for users of freebsd-stable. It includes
+ warnings about new features coming out in -stable that
+ will affect the users, and instructions on steps that must
+ be taken to remain -stable. Anyone running “stable”
+ should subscribe to this list. This is a technical mailing
+ list for which strictly technical content is
+ expected.
+
+
+
+ FREEBSD-USER-GROUPSUser Group Coordination
ListThis is the mailing list for the coordinators from
each of the local area Users Groups to discuss matters
with each other and a designated individual from the Core
Team. This mail list should be limited to meeting
synopsis and coordination of projects that span User
Groups. It is a closed list.Usenet newsgroupsIn addition to two FreeBSD specific newsgroups, there are many
others in which FreeBSD is discussed or are otherwise relevant to
FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.oz.au.BSD specific newsgroupscomp.unix.bsd.freebsd.announcecomp.unix.bsd.freebsd.miscOther Unix newsgroups of interestcomp.unixcomp.unix.questionscomp.unix.admincomp.unix.programmercomp.unix.shellcomp.unix.user-friendlycomp.security.unixcomp.sources.unixcomp.unix.advocacycomp.unix.misccomp.bugs.4bsdcomp.bugs.4bsd.ucb-fixescomp.unix.bsdX Window Systemcomp.windows.x.i386unixcomp.windows.xcomp.windows.x.appscomp.windows.x.announcecomp.windows.x.intrinsicscomp.windows.x.motifcomp.windows.x.pexcomp.emulators.ms-windows.wineWorld Wide Web servershttp://www.FreeBSD.ORG/ — Central Server.http://www.au.freebsd.org/FreeBSD/ — Australia.
+ URL="http://www.au.freebsd.org/FreeBSD/">http://www.au.freebsd.org/FreeBSD/ — Australia/1.
+
+
+
+ http://www2.au.freebsd.org/FreeBSD/ — Australia/2.
+
+
+
+ http://www3.au.freebsd.org/FreeBSD/ — Australia/3.
+
+
+
+ http://www.br.freebsd.org/www.freebsd.org/ — Brazil/1.
+
+
+
+ http://www.br2.freebsd.org/www.freebsd.org/ — Brazil/2.
+
+
+
+ http://www3.br.freebsd.org/ — Brazil/3.http://www.br.freebsd.org/ — Brazil.
+ URL="http://www.bg.freebsd.org/">http://www.bg.freebsd.org/ — Bulgaria.
http://www.ca.freebsd.org/ — Canada.
+ URL="http://www.ca.freebsd.org/">http://www.ca.freebsd.org/ — Canada/1.
http://sunsite.mff.cuni.cz/www.freebsd.org/ — Czech Republic.
+ URL="http://freebsd.kawartha.com/">http://freebsd.kawartha.com/ — Canada/2.
http://sunsite.auc.dk/www.freebsd.org/ — Denmark.
+ URL="http://www.dk.freebsd.org/">http://www.dk.freebsd.org/ — Denmark.
http://www.ee.freebsd.org/ — Estonia.http://www.fi.freebsd.org/ — Finland.
+
+
+ http://www.fr.freebsd.org/ — France.
+
+
+
+ http://www.de.freebsd.org/ — Germany/1.
+
+
+
+ http://www1.de.freebsd.org/ — Germany/2.
+
+
+
+ http://www.de.freebsd.org/ — Germany/3.
+
+
+
+ http://www.hu.freebsd.org/ — Hungary.
+ http://www.de.freebsd.org/ — Germany.
+ URL="http://www.is.freebsd.org/">http://www.is.freebsd.org/ — Iceland.
http://www.ie.freebsd.org/ — Ireland.http://www.jp.freebsd.org/ — Japan.
+ URL="http://www.jp.freebsd.org/www.freebsd.org/">http://www.jp.freebsd.org/www.freebsd.org/ — Japan.
http://www.kr.freebsd.org/ — Korea.
+
+ http://www.lv.freebsd.org/ — Latvia.
+
+
+
+ http://rama.asiapac.net/freebsd/ — Malaysia.
+
+
http://www.nl.freebsd.org/ — Netherlands.http://www.pt.freebsd.org/ — Portugal.
+ URL="http://www.no.freebsd.org/">http://www.no.freebsd.org/ — Norway.
+
+
+
+ http://www.pt.freebsd.org/ — Portugal/1.
+
+
+
+ http://www2.pt.freebsd.org/ — Portugal/2.
+
+
+
+ http://www3.pt.freebsd.org/ — Portugal/3.
+
+
+
+ http://www.ro.freebsd.org/ — Romania.
+
+
+
+ http://www.ru.freebsd.org/ — Russia/1.
+
+
+
+ http://www2.ru.freebsd.org/ — Russia/2.
+
+
+
+ http://www3.ru.freebsd.org/ — Russia/3.
+
+
+
+ http://www.sk.freebsd.org/ — Slovak Republic.
+
+
+
+ http://www.si.freebsd.org/ — Slovenia.
+
+
+
+ http://www.es.freebsd.org/ — Spain.
+
+
+
+ http://www.za.freebsd.org/ — South Africa/1.
+
+
+
+ http://www2.za.freebsd.org/ — South Africa/2.http://www.se.freebsd.org/www.freebsd.org/ — Sweden.http://www.tw.freebsd.org/freebsd.html — Taiwan.
+ URL="http://www.tr.freebsd.org/">http://www.tr.freebsd.org/ — Turkey.
+
+
+
+ http://www.ua.freebsd.org/ — Ukraine/1.
+
+
+
+ http://www2.ua.freebsd.org/ — Ukraine/2.
+
+
+
+ http://www.uk.freebsd.org/ — United Kingdom.
+
+
+
+ http://freebsd.advansys.net/ — USA/Indiana.http://www2.ua.freebsd.org/ — Ukraine.
+ URL="http://www6.freebsd.org/">http://www6.freebsd.org/ — USA/Oregon.
+
+ http://www2.freebsd.org/ — USA/Texas.
+
diff --git a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
index 163e13428a..77510aa99d 100644
--- a/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
@@ -1,622 +1,626 @@
IntroductionFreeBSD is a 4.4BSD-Lite based operating system for Intel
architecture (x86) based PCs. For an overview of FreeBSD, see
FreeBSD in a nutshell. For a
history of the project, read a brief
history of FreeBSD. To see a description of the latest release,
read about the current
release. If you're interested in contributing something to the
FreeBSD project (code, equipment, sacks of unmarked bills), please see
about contributing to FreeBSD.FreeBSD in a NutshellFreeBSD is a state of the art operating system for personal
computers based on the Intel CPU architecture, which includes the
386, 486 and Pentium processors (both SX and DX versions). Intel
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
provides you with many advanced features previously available only
on much more expensive computers. These features include:Preemptive multitasking with
dynamic priority adjustment to ensure smooth and fair sharing
of the computer between applications and users.Multiuser access means that
many people can use a FreeBSD system simultaneously for a
variety of things. System peripherals such as printers and
tape drives are also properly SHARED BETWEEN ALL users on the
system.Complete TCP/IP networking
including SLIP, PPP, NFS and NIS support. This means that
your FreeBSD machine can inter-operate easily with other
systems as well act as an enterprise server, providing vital
functions such as NFS (remote file access) and e-mail services
or putting your organization on the Internet with WWW, ftp,
routing and firewall (security) services.Memory protection ensures
that applications (or users) cannot interfere with each other.
One application crashing will not affect others in any
way.FreeBSD is a 32-bit
operating system and was designed as such from the ground
up.The industry standard X Window
System (X11R6) provides a graphical user
interface (GUI) for the cost of a common VGA card and monitor
and comes with full sources.Binary compatibility with
many programs built for SCO, BSDI, NetBSD, Linux and
386BSD.Hundreds of ready-to-run
applications are available from the FreeBSD ports and packages collection. Why search the net
when you can find it all right here?Thousands of additional and easy-to-port applications available on
the Internet. FreeBSD is source code compatible with most
popular commercial Unix systems and thus most applications
require few, if any, changes to compile.Demand paged virtual memory
and “merged VM/buffer cache” design efficiently satisfies
applications with large appetites for memory while still
maintaining interactive response to other users.Shared libraries (the Unix
equivalent of MS-Windows DLLs) provide for efficient use of
disk space and memory.A full complement of C,
C++ and Fortran development tools. Many
additional languages for advanced research and development are
also available in the ports and packages collection.Source code for the entire
system means you have the greatest degree of control over your
environment. Why be locked into a proprietary solution and at
the mercy of your vendor when you can have a truly Open
System?Extensive on-line
documentation.And many more!FreeBSD is based on the 4.4BSD-Lite release from Computer
Systems Research Group (CSRG) at the University of California at
Berkeley, and carries on the distinguished tradition of BSD systems
development. In addition to the fine work provided by CSRG, the
FreeBSD Project has put in many thousands of hours in fine tuning
the system for maximum performance and reliability in real-life load
situations. As many of the commercial giants struggle to field PC
operating systems with such features, performance and reliability,
FreeBSD can offer them now!The applications to which FreeBSD can be put are truly limited
only by your own imagination. From software development to factory
automation, inventory control to azimuth correction of remote
satellite antennae; if it can be done with a commercial UNIX product
then it is more than likely that you can do it with FreeBSD, too!
FreeBSD also benefits significantly from the literally thousands of
high quality applications developed by research centers and
universities around the world, often available at little to no cost.
Commercial applications are also available and appearing in greater
numbers every day.Because the source code for FreeBSD itself is generally
available, the system can also be customized to an almost unheard of
degree for special applications or projects, and in ways not
generally possible with operating systems from most major commercial
vendors. Here is just a sampling of some of the applications in
which people are currently using FreeBSD:Internet Services: The
robust TCP/IP networking built into FreeBSD makes it an ideal
platform for a variety of Internet services such as:FTP serversWorld Wide Web serversGopher serversElectronic Mail serversUSENET NewsBulletin Board SystemsAnd more...You can easily start out small with an
inexpensive 386 class PC and upgrade as your enterprise
grows.Education: Are you a student
of computer science or a related engineering field? There is
no better way of learning about operating systems, computer
architecture and networking than the hands on, under the hood
experience that FreeBSD can provide. A number of freely
available CAD, mathematical and graphic design packages also
make it highly useful to those whose primary interest in a
computer is to get other work
done!Research: With source code
for the entire system available, FreeBSD is an excellent
platform for research in operating systems as well as other
branches of computer science. FreeBSD's freely available
nature also makes it possible for remote groups to collaborate
on ideas or shared development without having to worry about
special licensing agreements or limitations on what may be
discussed in open forums.Networking: Need a new
router? A name server (DNS)? A firewall to keep people out
of your internal network? FreeBSD can easily turn that unused
386 or 486 PC sitting in the corner into an advanced router
with sophisticated packet filtering capabilities.X Window workstation:
FreeBSD is a fine choice for an inexpensive X terminal
solution, either using the freely available XFree86 server or
one of the excellent commercial servers provided by X Inside.
Unlike an X terminal, FreeBSD allows many applications to be
run locally, if desired, thus relieving the burden on a
central server. FreeBSD can even boot “diskless”, making
individual workstations even cheaper and easier to
administer.Software Development: The
basic FreeBSD system comes with a full complement of
development tools including the renowned GNU C/C++ compiler
and debugger.FreeBSD is available in both source and binary form on CDROM and
via anonymous ftp. See Obtaining
FreeBSD for more details.A Brief History of FreeBSDContributed by &a.jkh;.The FreeBSD project had its genesis in the early part of 1993,
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
myself.Our original goal was to produce an intermediate snapshot of
386BSD in order to fix a number of problems with it that the
patchkit mechanism just was not capable of solving. Some of you may
remember the early working title for the project being “386BSD 0.5”
or “386BSD Interim” in reference to that fact.386BSD was Bill Jolitz's operating system, which had been up to
that point suffering rather severely from almost a year's worth of
neglect. As the patchkit swelled ever more uncomfortably with each
passing day, we were in unanimous agreement that something had to be
done and decided to try and assist Bill by providing this interim
“cleanup” snapshot. Those plans came to a rude halt when Bill
Jolitz suddenly decided to withdraw his sanction from the project
and without any clear indication of what would be done
instead.It did not take us long to decide that the goal remained
worthwhile, even without Bill's support, and so we adopted the name
“FreeBSD”, coined by David Greenman. Our initial objectives were
set after consulting with the system's current users and, once it
became clear that the project was on the road to perhaps even
becoming a reality, I contacted Walnut Creek CDROM with an eye
towards improving FreeBSD's distribution channels for those many
unfortunates without easy access to the Internet. Walnut Creek
CDROM not only supported the idea of distributing FreeBSD on CD but
went so far as to provide the project with a machine to work on and
a fast Internet connection. Without Walnut Creek CDROM's almost
unprecedented degree of faith in what was, at the time, a completely
unknown project, it is quite unlikely that FreeBSD would have gotten
as far, as fast, as it has today.The first CDROM (and general net-wide) distribution was FreeBSD
1.0, released in December of 1993. This was based on the
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
also provided by 386BSD and the Free Software Foundation. It was a
fairly reasonable success for a first offering, and we followed it
with the highly successful FreeBSD 1.1 release in May of
1994.Around this time, some rather unexpected storm clouds formed on
the horizon as Novell and U.C. Berkeley settled their long-running
lawsuit over the legal status of the Berkeley Net/2 tape. A
condition of that settlement was U.C. Berkeley's concession that
large parts of Net/2 were “encumbered” code and the property of
Novell, who had in turn acquired it from AT&T some time
previously. What Berkeley got in return was Novell's “blessing”
that the 4.4BSD-Lite release, when it was finally released, would be
declared unencumbered and all existing Net/2 users would be strongly
encouraged to switch. This included FreeBSD, and the project was
given until the end of July 1994 to stop shipping its own Net/2
based product. Under the terms of that agreement, the project was
allowed one last release before the deadline, that release being
FreeBSD 1.1.5.1.FreeBSD then set about the arduous task of literally
re-inventing itself from a completely new and rather incomplete set
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
Berkeley's CSRG had removed large chunks of code required for
actually constructing a bootable running system (due to various
legal requirements) and the fact that the Intel port of 4.4 was
highly incomplete. It took the project until December of 1994 to
make this transition, and in January of 1995 it released FreeBSD 2.0
to the net and on CDROM. Despite being still more than a little
rough around the edges, the release was a significant success and
was followed by the more robust and easier to install FreeBSD 2.0.5
release in June of 1995.We released FreeBSD 2.1.5 in August of 1996, and it appeared to
be popular enough among the ISP and commercial communities that
another release along the 2.1-stable branch was merited. This was
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
mainstream development on 2.1-stable. Now in maintenance mode, only
security enhancements and other critical bug fixes will be done on
this branch (RELENG_2_1_0).FreeBSD 2.2 was branched from the development mainline
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
first full release (2.2.1) was released in April, 1997. Further
releases along the 2.2 branch were done in the Summer and Fall of
'97, the latest being 2.2.7 which appeared in late July of '98.
- The first official 3.0 release will appear in October, 1998 and the
- last release on the 2.2 branch, 2.2.8, will appear in November.
-
- Long term development projects for everything from SMP to DEC
- ALPHA support will continue to take place in the 3.0-current branch
- and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).
-
+ The first official 3.0 release appeared in October, 1998 and the
+ last release on the 2.2 branch, 2.2.8, appeared in November,
+ 1998.
+
+ The tree branched again on Jan 20, 1999. This led to
+ 4.0-current and a 3.x-stable branch, from which 3.1 will be
+ released on February 15th, 1999.
+
+ Long term development projects will continue to take place in
+ the 4.0-current branch and SNAPshot releases of 4.0 on CDROM (and,
+ of course, on the net).FreeBSD Project GoalsContributed by &a.jkh;.The goals of the FreeBSD Project are to provide software that
may be used for any purpose and without strings attached. Many of
us have a significant investment in the code (and project) and would
certainly not mind a little financial compensation now and then, but
we're definitely not prepared to insist on it. We believe that our
first and foremost “mission” is to provide code to any and all
comers, and for whatever purpose, so that the code gets the widest
possible use and provides the widest possible benefit. This is, I
believe, one of the most fundamental goals of Free Software and one
that we enthusiastically support.That code in our source tree which falls under the GNU Public
License (GPL) or GNU Library Public License (GLPL) comes with
slightly more strings attached, though at least on the side of
enforced access rather than the usual opposite. Due to the
additional complexities that can evolve in the commercial use of GPL
software, we do, however, endeavor to replace such software with
submissions under the more relaxed BSD copyright whenever possible.The FreeBSD Development ModelContributed by &a.asami;.The development of FreeBSD is a very open and flexible process,
FreeBSD being literally built from the contributions of hundreds of
people around the world, as can be seen from our list of contributors. We are constantly
on the lookout for new developers and ideas, and those interested in
becoming more closely involved with the project need simply contact
us at the &a.hackers;. Those who prefer to work more independently
are also accommodated, and they are free to use our FTP facilities
at ftp.freebsd.org to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.Useful things to know about the FreeBSD project and its
development process, whether working independently or in close
cooperation:The CVS
repositoryThe central source tree for FreeBSD is maintained by
CVS (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary CVS repository resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the -current and -stable trees which are checked
out of it, can be easily replicated to your own machine as
well. Please refer to the
Synchronizing your source
tree section for more information on doing this.The committers
listThe committers
are the people who have write access to
the CVS tree, and are thus authorized to make modifications
to the FreeBSD source (the term “committer” comes from the
cvs1commit command, which is used to
bring new changes into the CVS repository). The best way of
making submissions for review by the committers list is to
use the send-pr1 command, though if something appears to be jammed in the system then you may also reach them by sending mail to committers@freebsd.org.The FreeBSD core
teamThe FreeBSD core
team would be equivalent to the board of directors if
the FreeBSD Project were a company. The primary task of the
core team is to make sure the project, as a whole, is in
good shape and is heading in the right directions. Inviting
dedicated and responsible developers to join our group of
committers is one of the functions of the core team, as is
the recruitment of new core team members as others move on.
Most current members of the core team started as committers
who's addiction to the project got the better of
them.Some core team members also have specific areas of responsibility,
meaning that they are committed to ensuring that some large
portion of the system works as advertised.Most members of the core team are volunteers when it
comes to FreeBSD development and do not benefit from the
project financially, so “commitment” should also not be
misconstrued as meaning “guaranteed support.” The
“board of directors” analogy above is not
actually very accurate, and it may be more suitable to say
that these are the people who gave up their lives in favor
of FreeBSD against their better judgement! ;)Outside
contributorsLast, but definitely not least, the largest group of
developers are the users themselves who provide feedback and
bug-fixes to us on an almost constant basis. The primary
way of keeping in touch with FreeBSD's more non-centralized
development is to subscribe to the &a.hackers; (see mailing list
info) where such things are discussed.The list of
those who have contributed something which made its way into
our source tree is a long and growing one, so why not join
it by contributing something back to FreeBSD today?
:-)Providing code is not the only way of contributing to
the project; for a more complete list of things that need
doing, please refer to the how to
contribute section in this handbook.In summary, our development model is organized as a loose set of
concentric circles. The centralized model is designed for the
convenience of the users of FreeBSD, who are
thereby provided with an easy way of tracking one central code base,
not to keep potential contributors out! Our desire is to present a
stable operating system with a large set of coherent application programs that the users can easily install
and use, and this model works very well in accomplishing
that.All we ask of those who would join us as FreeBSD developers is
some of the same dedication its current people have to its continued
success!About the Current ReleaseFreeBSD is a freely available, full source 4.4BSD-Lite based
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
compatible) based PC's. It is based primarily on software from U.C.
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
386BSD, and the Free Software Foundation.Since our release of FreeBSD 2.0 in January of 95, the
performance, feature set, and stability of FreeBSD has improved
dramatically. The largest change is a revamped virtual memory
system with a merged VM/file buffer cache that not only increases
performance, but reduces FreeBSD's memory footprint, making a 5MB
configuration a more acceptable minimum. Other enhancements include
full NIS client and server support, transaction TCP support,
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
bug fixes.We have also taken the comments and suggestions of many of our
users to heart and have attempted to provide what we hope is a more
sane and easily understood installation process. Your feedback on
this (constantly evolving) process is especially welcome!In addition to the base distributions, FreeBSD offers a new
ported software collection with hundreds of commonly sought-after
programs. At the end of August 1998 there were more than 1700 ports!
The list of ports ranges from http (WWW) servers, to games,
languages, editors and almost everything in between. The entire
ports collection requires approximately 26MB of storage, all ports
being expressed as “deltas” to their original sources. This
makes it much easier for us to update ports, and greatly reduces
the disk space demands made by the older 1.0 ports collection. To
compile a port, you simply change to the directory of the program
you wish to install, type make all followed by make install
after successful compilation and let the system do the rest. The
full original distribution for each port you build is retrieved
dynamically off the CDROM or a local ftp site, so you need only
enough disk space to build the ports you want. (Almost) every port
is also provided as a pre-compiled “package” which can be installed
with a simple command (pkg_add) by those who do not wish to compile
their own ports from source.A number of additional documents which you may find very helpful
in the process of installing and using FreeBSD may now also be found
in the /usr/share/doc directory on any machine
running FreeBSD 2.1 or later. You may view the locally installed
manuals with any HTML capable browser using the following
URLs:The FreeBSD handbookfile:/usr/share/doc/handbook/handbook.htmlThe FreeBSD FAQfile:/usr/share/doc/FAQ/FAQ.htmlYou can also visit the master (and most frequently updated)
copies at http://www.freebsd.org.The core of FreeBSD does not contain DES code which would
inhibit its being exported outside the United States. There is an
add-on package to the core distribution, for use only in the United
States, that contains the programs that normally use DES. The
auxiliary packages provided separately can be used by anyone. A
freely (from outside the U.S.) exportable European distribution of
DES for our non-U.S. users also exists and is described in the
FreeBSD FAQ.If password security for FreeBSD is all you need, and you have
no requirement for copying encrypted passwords from different hosts
(Suns, DEC machines, etc) into FreeBSD password entries, then
FreeBSD's MD5 based security may be all you require! We feel that
our default security model is more than a match for DES, and without
any messy export issues to deal with. If you are outside (or even
inside) the U.S., give it a try!
diff --git a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml
index f40cd2f2d3..35d0fd1e36 100644
--- a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml
@@ -1,1709 +1,1711 @@
Configuring the FreeBSD KernelContributed by &a.jehamby;.6 October
1995.This large section of the handbook discusses the basics of
building your own custom kernel for FreeBSD. This section is
appropriate for both novice system administrators and those with
advanced Unix experience.Why Build a Custom Kernel?Building a custom kernel is one of the most important rites of
passage every Unix system administrator must endure. This process,
while time-consuming, will provide many benefits to your FreeBSD
system. Unlike the GENERIC kernel, which must support every
possible SCSI and network card, along with tons of other rarely used
hardware support, a custom kernel only contains support for
your PC's hardware. This has a number of
benefits:It will take less time to boot because it does not have to
spend time probing for hardware which you do not have.A custom kernel often uses less memory, which is important
because the kernel is the one process which must always be
present in memory, and so all of that unused code ties up
pages of RAM that your programs would otherwise be able to
use. Therefore, on a system with limited RAM, building a
custom kernel is of critical importance.Finally, there are several kernel options which you can
tune to fit your needs, and device driver support for things
like sound cards which you can include in your kernel but are
not present in the GENERIC kernel.Building and Installing a Custom KernelFirst, let us take a quick tour of the kernel build directory.
All directories mentioned will be relative to the main
/usr/src/sys directory, which is also
accessible through /sys. There are a number of
subdirectories here representing different parts of the kernel, but
the most important, for our purposes, are
i386/conf, where you will edit your custom
kernel configuration, and compile,
which is the staging area where your kernel will be built. Notice
the logical organization of the directory tree, with each supported
device, filesystem, and option in its own subdirectory. Also,
anything inside the i386 directory deals with
PC hardware only, while everything outside the
i386 directory is common to all platforms which
FreeBSD could potentially be ported to.If there is not a
/usr/src/sys directory on your system, then
- the kernel source has not been been installed. Follow the
- instructions for installing packages to add this package to your
- system.
+ the kernel source has not been been installed. The easiest way
+ to do this is by running /stand/sysinstall as
+ root, choosing Configure,
+ then Distributions, then src,
+ then sys.
Next, move to the i386/conf directory and
copy the GENERIC configuration file to the name
you want to give your kernel. For example:&prompt.root; cd /usr/src/sys/i386/conf
&prompt.root; cp GENERIC MYKERNELTraditionally, this name is in all capital
letters and, if you are maintaining multiple FreeBSD machines with
different hardware, it is a good idea to name it after your
machine's hostname. We will call it MYKERNEL
for the purpose of this example.You must execute these and all of the following commands
under the root account or you will get permission denied
errors.Now, edit MYKERNEL with your favorite text
editor. If you are just starting out, the only editor available
will probably be vi, which is too
complex to explain here, but is covered well in many books in the
bibliography. Feel free to change
the comment lines at the top to reflect your configuration or the
changes you have made to differentiate it from
GENERIC.If you have build a kernel under SunOS or some other BSD
operating system, much of this file will be very familiar to you. If
you are coming from some other operating system such as DOS, on the
other hand, the GENERIC configuration file
might seem overwhelming to you, so follow the descriptions in the
Configuration File section slowly and carefully.If you are trying to upgrade your kernel from an older version
of FreeBSD, you will probably have to get a new version of
config8 from the same place you got the new
kernel sources. It is located in
/usr/src/usr.sbin, so you will need to
download those sources as well. Re-build and install it before
running the next commands.When you are finished, type the following to compile and install
your kernel:&prompt.root; /usr/sbin/config MYKERNEL
&prompt.root; cd ../../compile/MYKERNEL
&prompt.root; make depend
&prompt.root; make
&prompt.root; make installThe new kernel will be copied to the root
directory as /kernel and the old kernel will be
moved to /kernel.old. Now, shutdown the system
and reboot to use your kernel. In case something goes wrong, there
are some troubleshooting instructions at the end of this document.
Be sure to read the section which explains how to recover in case
your new kernel does not boot.If you have added any new devices (such as sound cards) you
may have to add some device nodes to your
/dev directory before you can use
them.The Configuration FileThe general format of a configuration file is quite simple. Each
line contains a keyword and one or more arguments. For simplicity,
most lines only contain one argument. Anything following a
# is considered a comment and ignored.
The following sections describe each keyword, generally in the order
they are listed in GENERIC, although some
related keywords have been grouped together in a single section
(such as Networking) even though they are actually scattered
throughout the GENERIC file.
An exhaustive list of options and
more detailed explanations of the device lines is present in the
LINT configuration file, located in the same
directory as GENERIC. If you are in doubt as to
the purpose or necessity of a line, check first in
LINT.The kernel is currently being moved to a better organization of
the option handling. Traditionally, each option in the config file
was simply converted into a switch for the
CFLAGS line of the kernel Makefile. Naturally,
this caused a creeping optionism, with nobody really knowing which
option has been referenced in what files.In the new scheme, every #ifdef
that is intended to be dependent upon an option gets this option out
of an opt_foo.h
declaration file created in the compile directory by config. The list of valid options for
config lives in two files: options
that do not depend on the architecture are listed in
/sys/conf/options, architecture-dependent ones
in
/sys/arch/conf/options.arch, with arch being for example i386.Mandatory KeywordsThese keywords are required in every kernel you build.machine "i386"The first keyword is machine, which, since FreeBSD only
runs on Intel 386 and compatible chips, is i386.Any keyword which contains numbers used as text
must be enclosed in quotation marks, otherwise
config gets confused and thinks you
mean the actual number 386.cpu "cpu_type"The next keyword is cpu,
which includes support for each CPU supported by FreeBSD.
The possible values of cpu_type
include:I386_CPUI486_CPUI586_CPUI686_CPUMultiple instances of the cpu line may be present with
different values of cpu_type
as are present in the GENERIC kernel.
For a custom kernel, it is best to specify only the cpu
you have. If, for example, you have an Intel Pentium, use
I586_CPU for cpu_type.ident machine_nameNext, we have ident,
which is the identification of the kernel. You should
change this from GENERIC to whatever
you named your kernel, in this example,
MYKERNEL. The value you put in
ident will print when you
boot up the kernel, so it is useful to give a kernel a
different name if you want to keep it separate from your
usual kernel (if you want to build an experimental kernel,
for example). Note that, as with machine and
cpu, enclose your kernel's name in quotation
marks if it contains any numbers.Since this name is passed to the C compiler as a
switch, do not use names like
DEBUG, or something that could be
confused with another machine or CPU name, like vax.maxusers numberThis file sets the size of a number of important
system tables. This number is supposed to be roughly
equal to the number of simultaneous users you expect to
have on your machine. However, under normal
circumstances, you will want to set
maxusers to at least 4,
especially if you are using the X Window System or
compiling software. The reason is that the most important
table set by maxusers is the
maximum number of processes, which is set to 20 + 16 *
maxusers, so if you set
maxusers to 1, then you
can only have 36 simultaneous processes, including the 18
or so that the system starts up at boot time, and the 15
or so you will probably create when you start the X Window
System. Even a simple task like reading a man page will start up nine
processes to filter, decompress, and view it. Setting
maxusers to 4 will allow you
to have up to 84 simultaneous processes, which should be
enough for anyone. If, however, you see the dreaded
proc table full error when trying to start another
program, or are running a server with a large number of
simultaneous users (like Walnut Creek CDROM's FTP site),
you can always increase this number and rebuild.maxuser does
not limit the number of users which
can log into your machine. It simply sets various table
sizes to reasonable values considering the maximum
number of users you will likely have on your system and
how many processes each of them will be running. One
keyword which does limit the number
of simultaneous remote logins is
pseudo-device pty
16.config kernel_name root on
root_deviceThis line specifies the location and name of the
kernel. Traditionally the kernel is called
vmunix but in FreeBSD, it is aptly
named kernel. You should always use
kernel for
kernel_name because changing it will
render numerous system utilities inoperative. The second
part of the line specifies the disk and partition where
the root filesystem and kernel can be found. Typically
this will be wd0 for systems
with non-SCSI drives, or sd0
for systems with SCSI drives.General OptionsThese lines provide kernel support for various filesystems and
other options.options MATH_EMULATEThis line allows the kernel to simulate a math
co-processor if your computer does not have one (386 or
486SX). If you have a Pentium, a 486DX, or a 386 or 486SX
with a separate 387 or 487 chip, you can comment this line
out.The normal math co-processor emulation routines that
come with FreeBSD are not very
accurate. If you do not have a math co-processor, and
you need the best accuracy, I recommend that you change
this option to GPL_MATH_EMULATE to use
the superior GNU math support, which is not included by
default for licensing reasons.options "COMPAT_43"Compatibility with 4.3BSD. Leave this in; some
programs will act strangely if you comment this
out.options BOUNCE_BUFFERSISA devices and EISA devices operating in an ISA
compatibility mode can only perform DMA (Direct Memory
Access) to memory below 16 megabytes. This option enables
such devices to work in systems with more than 16
megabytes of memory.options UCONSOLEAllow users to grab the console, useful for X Windows.
For example, you can create a console xterm by typing
xterm -C, which will display any
write, talk, and other messages you receive, as well
as any console messages sent by the kernel.options SYSVSHMThis option provides for System V shared memory. The
most common use of this is the XSHM extension in X
Windows, which many graphics-intensive programs (such as
the movie player XAnim, and Linux DOOM) will automatically
take advantage of for extra speed. If you use the X
Window System, you will definitely want to include
this.options SYSVSEMSupport for System V semaphores. Less commonly used
but only adds a few hundred bytes to the kernel.options SYSVMSGSupport for System V messages. Again, only adds a few
hundred bytes to the kernel.The ipcs1 command will tell
will list any processes using each of these System V
facilities.Filesystem OptionsThese options add support for various filesystems. You must
include at least one of these to support the device you boot from;
typically this will be FFS if you boot from a
hard drive, or NFS if you are booting a
diskless workstation from Ethernet. You can include other
commonly-used filesystems in the kernel, but feel free to comment
out support for filesystems you use less often (perhaps the MS-DOS
filesystem?), since they will be dynamically loaded from the
Loadable Kernel Module directory /lkm the
first time you mount a partition of that type.options FFSThe basic hard drive filesystem; leave it in if you
boot from the hard disk.options NFSNetwork Filesystem. Unless you plan to mount
partitions from a Unix file server over Ethernet, you can
comment this out.options MSDOSFSMS-DOS Filesystem. Unless you plan to mount a DOS
formatted hard drive partition at boot time, you can
safely comment this out. It will be automatically loaded
the first time you mount a DOS partition, as described
above. Also, the excellent mtools software (in the ports
collection) allows you to access DOS floppies without
having to mount and unmount them (and does not require
MSDOSFS at all).options "CD9660"ISO 9660 filesystem for CD-ROMs. Comment it out if
you do not have a CD-ROM drive or only mount data CD's
occasionally (since it will be dynamically loaded the
first time you mount a data CD). Audio CD's do not need
this filesystem.options PROCFSProcess filesystem. This is a pretend filesystem
mounted on /proc which allows
programs like ps1 to give you more
information on what processes are running.options MFSMemory-mapped file system. This is basically a RAM
disk for fast storage of temporary files, useful if you
have a lot of swap space that you want to take advantage
of. A perfect place to mount an MFS partition is on the
/tmp directory, since many programs
store temporary data here. To mount an MFS RAM disk on
/tmp, add the following line to
/etc/fstab and then reboot or type
mount /tmp:
/dev/wd1s2b /tmp mfs rw 0 0Replace the /dev/wd1s2b with
the name of your swap partition, which will be listed in
your /etc/fstab as follows:
/dev/wd1s2b none swap sw 0 0Also, the MFS filesystem can
not be dynamically loaded, so you
must compile it into your kernel if
you want to experiment with it.options "EXT2FS"Linux's native file system. With ext2fs support you
are able to read and write to Linux partitions. This is
useful if you dual-boot FreeBSD and Linux and want to
share data between the two systems.options QUOTAEnable disk quotas. If you have a public access
system, and do not want users to be able to overflow the
/home partition, you can establish
disk quotas for each user. Refer to the
Disk Quotas section for
more information.Basic Controllers and DevicesThese sections describe the basic disk, tape, and CD-ROM
controllers supported by FreeBSD. There are separate sections for
SCSI controllers and network cards.controller isa0All PC's supported by FreeBSD have one of these. If
you have an IBM PS/2 (Micro Channel Architecture), then
you cannot run FreeBSD at this time.controller pci0Include this if you have a PCI motherboard. This
enables auto-detection of PCI cards and gatewaying from
the PCI to the ISA bus.controller fdc0Floppy drive controller: fd0 is the
A: floppy drive, and
fd1 is the B: drive.
ft0 is a QIC-80 tape drive
attached to the floppy controller. Comment out any lines
corresponding to devices you do not have.QIC-80 tape support requires a separate filter
program called ft8, see the manual
page for details.controller wdc0This is the primary IDE controller. wd0 and wd1 are the master and slave hard
drive, respectively. wdc1 is
a secondary IDE controller where you might have a third or
fourth hard drive, or an IDE CD-ROM. Comment out the
lines which do not apply (if you have a SCSI hard drive,
you will probably want to comment out all six lines, for
example).device wcd0This device provides IDE CD-ROM support. Be sure to
leave wdc0 uncommented, and
wdc1 if you have more than
one IDE controller and your CD-ROM is on the second one
card. To use this, you must also include the line
options ATAPI.device npx0 at isa? port "IO_NPX" irq 13
vector npxintrnpx0 is the interface to
the floating point math unit in FreeBSD, either the
hardware co-processor or the software math emulator. It
is not optional.device wt0 at isa? port 0x300 bio irq 5 drq
1 vector wtintrWangtek and Archive QIC-02/QIC-36 tape drive
supportProprietary CD-ROM supportThe following drivers are for the so-called
proprietary CD-ROM drives. These
drives have their own controller card or might plug into a
sound card such as the SoundBlaster 16. They are
not IDE or SCSI. Most older
single-speed and double-speed CD-ROMs use these
interfaces, while newer quad-speeds are likely to be IDE or SCSI.device mcd0 at isa? port 0x300 bio
irq 10 vector mcdintrMitsumi CD-ROM (LU002, LU005, FX001D).device scd0 at isa? port 0x230
bioSony CD-ROM (CDU31, CDU33A).controller matcd0 at isa? port ?
bioMatsushita/Panasonic CD-ROM (sold by Creative
Labs for SoundBlaster).SCSI Device SupportThis section describes the various SCSI controllers and
devices supported by FreeBSD.SCSI ControllersThe next ten or so lines include support for different
kinds of SCSI controllers. Comment out all except for the
one(s) you have:controller bt0 at isa? port
"IO_BT0" bio irq ? vector btintrMost Buslogic controllerscontroller uha0 at isa? port
"IO_UHA0" bio irq ? drq 5 vector uhaintrUltraStor 14F and 34Fcontroller ahc0Adaptec 274x/284x/294xcontroller ahb0 at isa? bio irq ?
vector ahbintrAdaptec 174xcontroller aha0 at isa? port
"IO_AHA0" bio irq ? drq 5 vector ahaintrAdaptec 154xcontroller aic0 at isa? port
0x340 bio irq 11 vector aicintrAdaptec 152x and sound cards using Adaptec
AIC-6360 (slow!)controller nca0 at isa? port
0x1f88 bio irq 10 vector ncaintrProAudioSpectrum cards using NCR 5380 or
Trantor T130controller sea0 at isa? bio irq 5
iomem 0xc8000 iosiz 0x2000 vector seaintrSeagate ST01/02 8 bit controller
(slow!)controller wds0 at isa? port
0x350 bio irq 15 drq 6 vector wdsintrWestern Digital WD7000 controllercontroller ncr0NCR 53C810, 53C815, 53C825, 53C860, 53C875 PCI
SCSI controlleroptions "SCSI_DELAY=15"This causes the kernel to pause 15 seconds before
probing each SCSI device in your system. If you only have
IDE hard drives, you can ignore this, otherwise you will
probably want to lower this number, perhaps to 5 seconds,
to speed up booting. Of course if you do this, and
FreeBSD has trouble recognizing your SCSI devices, you
will have to raise it back up.controller scbus0If you have any SCSI controllers, this line provides
generic SCSI support. If you do not have SCSI, you can
comment this, and the following three lines, out.device sd0Support for SCSI hard drives.device st0Support for SCSI tape drives.device cd0Support for SCSI CD-ROM drives.Note that the number 0
in the above entries is slightly misleading: all these
devices are automatically configured as they are found,
regardless of how many of them are hooked up to the SCSI
bus(es), and which target IDs they have.If you want to “wire down” specific target IDs to
particular devices, refer to the appropriate section of
the LINT kernel config file.Console, Bus Mouse, and X Server SupportYou must choose one of these two console types, and, if you
plan to use the X Window System with the vt220 console, enable the
XSERVER option and optionally, a bus mouse or PS/2 mouse
device.device sc0 at isa? port "IO_KBD" tty irq 1
vector scintrsc0 is the default
console driver, which resembles an SCO console. Since most
full-screen programs access the console through a terminal
database library like termcap, it
should not matter much whether you use this or vt0, the VT220 compatible console
driver. When you log in, set your TERM variable to
“scoansi” if full-screen programs have trouble running
under this console.device vt0 at isa? port "IO_KBD" tty irq 1
vector pcrintThis is a VT220-compatible console driver, backwards
compatible to VT100/102. It works well on some laptops
which have hardware incompatibilities with sc0. Also, set your TERM variable
to vt100 or vt220 when you log in. This driver
might also prove useful when connecting to a large number
of different machines over the network, where the
termcap or
terminfo entries for the sc0 device are often not available
— vt100 should be available on virtually any
platform.options "PCVT_FREEBSD=210"Required with the vt0 console driver.options XSERVEROnly applicable with the vt0 console driver. This
includes code required to run the XFree86 X Window Server
under the vt0
console driver.device mse0 at isa? port 0x23c tty irq 5
vector msUse this device if you have a Logitech or ATI InPort
bus mouse card.If you have a serial mouse, ignore these two lines,
and instead, make sure the appropriate serial port is enabled (probably
COM1).device psm0 at isa? port "IO_KBD"
conflicts tty irq 12 vector psmintrUse this device if your mouse plugs into the PS/2
mouse port.Serial and Parallel PortsNearly all systems have these. If you are attaching a printer
to one of these ports, the Printing section of the handbook is very useful. If
you are using modem, Dialup access provides extensive detail on serial port
configuration for use with such devices.device sio0 at isa? port "IO_COM1" tty irq
4 vector siointrsio0 through sio3 are the four serial ports
referred to as COM1 through COM4 in the MS-DOS world.
Note that if you have an internal modem on COM4 and a
serial port at COM2 you will have to change the IRQ of the
modem to 2 (for obscure technical reasons IRQ 2 = IRQ 9)
in order to access it from FreeBSD. If you have a
multiport serial card, check the manual page for
sio4 for more information on the
proper values for these lines. Some video cards (notably
those based on S3 chips) use IO addresses of the form
0x*2e8, and since many cheap serial
cards do not fully decode the 16-bit IO address space,
they clash with these cards, making the COM4 port
practically unavailable.Each serial port is required to have a unique IRQ
(unless you are using one of the multiport cards where
shared interrupts are supported), so the default IRQs for
COM3 and COM4 cannot be used.device lpt0 at isa? port? tty irq 7 vector
lptintrlpt0 through lpt2 are the three printer ports you
could conceivably have. Most people just have one,
though, so feel free to comment out the other two lines if
you do not have them.NetworkingFreeBSD, as with Unix in general, places a
big emphasis on networking. Therefore, even
if you do not have an Ethernet card, pay attention to the
mandatory options and the dial-up networking support.options INETNetworking support. Leave it in even if you do not
plan to be connected to a network. Most programs require
at least loopback networking (i.e. making network
connections within your PC) so this is essentially
mandatory.Ethernet cardsThe next lines enable support for various Ethernet
cards. If you do not have a network card, you can comment
out all of these lines. Otherwise, you will want to leave
in support for your particular Ethernet card(s):device de0Ethernet adapters based on Digital Equipment
DC21040, DC21041 or DC21140 chipsdevice fxp0Intel EtherExpress Pro/100Bdevice vx03Com 3C590 and 3C595 (buggy)device cx0 at isa? port 0x240 net
irq 15 drq 7 vector cxintrCronyx/Sigma multiport sync/async (with Cisco
or PPP framing)device ed0 at isa? port 0x280 net
irq 5 iomem 0xd8000 vector edintrWestern Digital and SMC 80xx and 8216; Novell
NE1000 and NE2000; 3Com 3C503; HP PC Lan Plus
(HP27247B and HP27252A)device el0 at isa? port 0x300 net
irq 9 vector elintr3Com 3C501 (slow!)device eg0 at isa? port 0x310 net
irq 5 vector egintr3Com 3C505device ep0 at isa? port 0x300 net
irq 10 vector epintr3Com 3C509 (buggy)device fe0 at isa? port 0x240 net
irq ? vector feintrFujitsu MB86960A/MB86965A Ethernetdevice fea0 at isa? net irq ? vector
feaintrDEC DEFEA EISA FDDI adapterdevice ie0 at isa? port 0x360 net
irq 7 iomem 0xd0000 vector ieintrAT&T StarLAN 10 and EN100; 3Com 3C507;
unknown NI5210; Intel EtherExpress 16device le0 at isa? port 0x300 net
irq 5 iomem 0xd0000 vector le_intrDigital Equipment EtherWorks 2 and EtherWorks
3 (DEPCA, DE100, DE101, DE200, DE201, DE202,
DE203, DE204, DE205, DE422)device lnc0 at isa? port 0x300 net
irq 10 drq 0 vector lncintrLance/PCnet cards (Isolan, Novell NE2100,
NE32-VL)device xl03Com Etherlink XL series PCI ethernet
controllers (3C905B and related).device ze0 at isa? port 0x300 net
irq 5 iomem 0xd8000 vector zeintrIBM/National Semiconductor PCMCIA ethernet
controller.device zp0 at isa? port 0x300 net
irq 10 iomem 0xd8000 vector zpintr3Com PCMCIA Etherlink IIIWith certain cards (notably the NE2000) you will
have to change the port and/or IRQ since there is no
“standard” location for these cards.pseudo-device looploop is the generic
loopback device for TCP/IP. If you telnet or FTP to
localhost (a.k.a. 127.0.0.1) it will come back at you
through this pseudo-device. Mandatory.pseudo-device etherether is only needed if
you have an Ethernet card and includes generic Ethernet
protocol code.pseudo-device sl
numbersl is for SLIP (Serial
Line Internet Protocol) support. This has been almost
entirely supplanted by PPP, which is easier to set up,
better suited for modem-to-modem connections, as well as
more powerful. The number after
sl specifies how many
simultaneous SLIP sessions to support. This handbook has
more information on setting up a SLIP client or server.pseudo-device ppp
numberppp is for kernel-mode
PPP (Point-to-Point Protocol) support for dial-up Internet
connections. There is also version of PPP implemented as a
user application that uses the tun and offers more flexibility and
features such as demand dialing. If you still want to use
this PPP driver, read the kernel-mode PPP
section of the handbook. As with the sl device,
number specifies how many
simultaneous PPP connections to support.pseudo-device tun
numbertun is used by the
user-mode PPP software. This program is easy to set up and
very fast. It also has special features such as automatic
dial-on-demand. The number after tun specifies the number of
simultaneous PPP sessions to support. See the user-mode PPP section of the handbook for more
information.pseudo-device bpfilter
numberBerkeley packet filter. This pseudo-device allows
network interfaces to be placed in promiscuous mode,
capturing every packet on a broadcast network (e.g. an
ethernet). These packets can be captured to disk and/or
examined with the tcpdump1 program.
Note that implementation of this capability can seriously
compromise your overall network security. The
number after bpfilter is the number
of interfaces that can be examined simultaneously.
Optional, not recommended except for those who are fully
aware of the potential pitfalls. Not all network cards
support this capability.Sound cardsThis is the first section containing lines that are not in the
GENERIC kernel. To include sound card support, you will have to
copy the appropriate lines from the LINT kernel (which contains
support for every device) as follows:controller snd0Generic sound driver code. Required for all of the
following sound cards except pca.device pas0 at isa? port 0x388 irq 10 drq 6
vector pasintrProAudioSpectrum digital audio and MIDI.device sb0 at isa? port 0x220 irq 7
conflicts drq 1 vector sbintrSoundBlaster digital audio.If your SoundBlaster is on a different IRQ (such as
5), change irq 7 to, for
example, irq 5 and remove
the conflicts keyword.
Also, you must add the line: options
"SBC_IRQ=5"device sbxvi0 at isa? drq 5SoundBlaster 16 digital 16-bit audio.If your SB16 is on a different 16-bit DMA channel
(such as 6 or 7), change the drq
5 keyword appropriately, and then add the
line: options "SB16_DMA=6"device sbmidi0 at isa? port 0x330SoundBlaster 16 MIDI interface. If you have a
SoundBlaster 16, you must include this line, or the kernel
will not compile.device gus0 at isa? port 0x220 irq 10 drq 1
vector gusintrGravis Ultrasound.device mss0 at isa? port 0x530 irq 10 drq 1
vector adintrMicrosoft Sound System.device opl0 at isa? port 0x388
conflictsAdLib FM-synthesis audio. Include this line for
AdLib, SoundBlaster, and ProAudioSpectrum users, if you
want to play MIDI songs with a program such as playmidi (in the ports
collection).device mpu0 at isa? port 0x330 irq 6 drq
0Roland MPU-401 stand-alone card.device uart0 at isa? port 0x330 irq 5 vector
"m6850intr"Stand-alone 6850 UART for MIDI.device pca0 at isa? port "IO_TIMER1"
ttyDigital audio through PC speaker. This is going to be
very poor sound quality and quite CPU-intensive, so you
have been warned (but it does not require a sound
card).There is some additional documentation in
/usr/src/sys/i386/isa/sound/sound.doc.
Also, if you add any of these devices, be sure to create the
sound device nodes.Pseudo-devicesPseudo-device drivers are parts of the kernel that act like
device drivers but do not correspond to any actual hardware in the
machine. The network-related pseudo-devices are in that section,
while the remainder are here.pseudo-device gzipgzip allows you to run
FreeBSD programs that have been compressed with gzip. The programs in
/stand are compressed so it is a good
idea to have this option in your kernel.pseudo-device loglog is used for logging
of kernel error messages. Mandatory.pseudo-device pty
numberpty is a
“pseudo-terminal” or simulated login port. It is used
by incoming telnet and
rlogin sessions, xterm, and
some other applications such as emacs. The
number indicates the number of
ptys to create. If you need
more than GENERIC default of 16 simultaneous xterm windows
and/or remote logins, be sure to increase this number
accordingly, up to a maximum of 256.pseudo-device snp
numberSnoop device. This pseudo-device allows one terminal
session to watch another using the
watch8 command. Note that
implementation of this capability has important security
and privacy implications. The number
after snp is the total number of simultaneous snoop
sessions. Optional.pseudo-device vnVnode driver. Allows a file to be treated as a device
after being set up with the vnconfig8
command. This driver can be useful for manipulating
floppy disk images and using a file as a swap device (e.g.
an MS Windows swap file). Optional.pseudo-device ccd
numberConcatenated disks. This pseudo-device allows you to
concatenate multiple disk partitions into one large
“meta”-disk. The number after ccd
is the total number of concatenated disks (not total
number of disks that can be concatenated) that can be
created. (See ccd4 and
ccdconfig8 man pages for more
details.) Optional.Joystick, PC Speaker, MiscellaneousThis section describes some miscellaneous hardware devices
supported by FreeBSD. Note that none of these lines are included
in the GENERIC kernel, you will have to copy them from this
handbook or the LINT kernel (which contains support for
every device):device joy0 at isa? port "IO_GAME"PC joystick device.pseudo-device speakerSupports IBM BASIC-style noises through the PC
speaker. Some fun programs which use this are
/usr/sbin/spkrtest, which is a shell
script that plays some simple songs, and
/usr/games/piano which lets you play
songs using the keyboard as a simple piano (this file only
exists if you have installed the
games package). Also, the excellent
text role-playing game NetHack (in the ports collection)
can be configured to use this device to play songs when
you play musical instruments in the game.See also the pca0 device.Making Device NodesAlmost every device in the kernel has a corresponding “node”
entry in the /dev directory. These nodes look
like regular files, but are actually special entries into the kernel
which programs use to access the device. The shell script
/dev/MAKEDEV, which is executed when you first
install the operating system, creates nearly all of the device nodes
supported. However, it does not create all of
them, so when you add support for a new device, it pays to make sure
that the appropriate entries are in this directory, and if not, add
them. Here is a simple example:Suppose you add the IDE CD-ROM support to the kernel. The line
to add is:
controller wcd0This means that you should look for some entries
that start with wcd0 in the
/dev directory, possibly followed by a letter,
such as c, or preceded by the letter r, which means a “raw”
device. It turns out that those files are not there, so I must
change to the /dev directory and type:&prompt.root; sh MAKEDEV wcd0When this script finishes, you will find that
there are now wcd0c and rwcd0c entries in /dev so
you know that it executed correctly.For sound cards, the command:
&prompt.root; sh MAKEDEV snd0 creates the appropriate entries.When creating device nodes for devices such as sound cards, if
other people have access to your machine, it may be desirable to
protect the devices from outside access by adding them to the
/etc/fbtab file. See man
fbtab for more information.Follow this simple procedure for any other non-GENERIC devices
which do not have entries.All SCSI controllers use the same set of
/dev entries, so you do not need to create
these. Also, network cards and SLIP/PPP pseudo-devices do not
have entries in /dev at all, so you do not
have to worry about these either.If Something Goes WrongThere are four categories of trouble that can occur when
building a custom kernel. They are:Config command failsIf the config command
fails when you give it your kernel description, you have
probably made a simple error somewhere. Fortunately,
config will print the line
number that it had trouble with, so you can quickly skip to
it with vi. For example, if
you see:
config: line 17: syntax error you can skip to the problem in vi by typing 17G in command mode.
Make sure the keyword is typed correctly, by comparing it to
the GENERIC kernel or another reference.Make command failsIf the make command fails,
it usually signals an error in your kernel description, but
not severe enough for config
to catch it. Again, look over your configuration, and if
you still cannot resolve the problem, send mail to the
&a.questions; with your kernel configuration, and it should
be diagnosed very quickly.Kernel will not bootIf your new kernel does not boot, or fails to recognize
your devices, do not panic! Fortunately, BSD has an
excellent mechanism for recovering from incompatible
kernels. Simply type the name of the kernel you want to boot
from (i.e. kernel.old) at the FreeBSD boot prompt
instead of pressing return. When reconfiguring a kernel, it
is always a good idea to keep a kernel that is known to work
on hand.After booting with a good kernel you can check over your
configuration file and try to build it again. One helpful
resource is the /var/log/messages file
which records, among other things, all of the kernel
messages from every successful boot. Also, the
dmesg8 command will print the kernel
messages from the current boot.If you are having trouble building a kernel, make sure
to keep a GENERIC, or some other kernel that is known to
work on hand as a different name that will not get erased
on the next build. You cannot rely on
kernel.old because when installing a
new kernel, kernel.old is overwritten
with the last installed kernel which may be
non-functional. Also, as soon as possible, move the
working kernel to the proper kernel location or
commands such as ps1 will not work
properly. The proper command to “unlock” the
kernel file that make installs (in
order to move another kernel back permanently) is:&prompt.root; chflags noschg /kernelAnd, if you want to
“lock” your new kernel into place, or any
file for that matter, so that it cannot be moved or
tampered with:&prompt.root; chflags schg /kernelKernel works, but ps does not work any more!If you have installed a different version of the kernel
from the one that the system utilities have been built with,
for example, an experimental “2.2.0” kernel on a
2.1.0-RELEASE system, many system-status commands like
ps1 and vmstat8
will not work any more. You must recompile the libkvm library as well as these
utilities. This is one reason it is not normally a good
idea to use a different version of the kernel from the rest
of the operating system.
diff --git a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
index 0e2bc3b76d..044c736cf4 100644
--- a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
@@ -1,860 +1,860 @@
Linux EmulationContributed by &a.handy; and &a.rich;How to Install the Linux EmulatorLinux emulation in FreeBSD has reached a point where it is
possible to run a large fraction of Linux binaries in both a.out and
ELF format. The linux emulation in the 2.1-STABLE branch is capable
of running Linux DOOM and Mathematica; the version present in
&rel.current;-RELEASE is vastly more capable and runs all these as
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
other programs.There are some Linux-specific operating system features that are
not supported on FreeBSD. Linux binaries will not work on FreeBSD
if they use the Linux /proc filesystem (which
is different from the optional FreeBSD /proc
filesystem) or i386-specific calls, such as enabling virtual 8086
mode.Depending on which version of FreeBSD you are running, how you
get Linux-emulation up will vary slightly:Installing Linux Emulation in 2.1-STABLEThe GENERIC kernel in 2.1-STABLE is not
configured for linux compatibility so you must reconfigure your
kernel for it. There are two ways to do this: 1. linking the
emulator statically in the kernel itself and 2. configuring your
kernel to dynamically load the linux loadable kernel module
(LKM).To enable the emulator, add the following to your
configuration file (c.f.
/sys/i386/conf/LINT):
options COMPAT_LINUXIf you want to run doom or other applications
that need shared memory, also add the following.
options SYSVSHMThe linux system calls require 4.3BSD system
call compatibility. So make sure you have the following.
options "COMPAT_43"If you prefer to statically link the emulator in the kernel
rather than use the loadable kernel module (LKM), then add
options LINUXThen run config and install the new kernel as
described in the
kernel configuration
section.If you decide to use the LKM you must also install the
loadable module. A mismatch of versions between the kernel and
loadable module can cause the kernel to crash, so the safest thing
to do is to reinstall the LKM when you install the kernel.&prompt.root; cd /usr/src/lkm/linux
&prompt.root; make all installOnce you have installed the kernel and the LKM,
you can invoke `linux' as root to load the LKM.&prompt.root; linux
Linux emulator installed
Module loaded as ID 0To see whether the LKM is loaded, run
modstat.&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulatorYou can cause the LKM to be loaded when the
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
2.1-STABLE enable it in /etc/sysconfig
linux=YES by changing it from NO to YES. FreeBSD 2.1
RELEASE and earlier do not have such a line and on those you will
need to edit /etc/rc.local to add the following line.
linuxInstalling Linux Emulation in 2.2.2-RELEASE and laterIt is no longer necessary to specify options LINUX or
options COMPAT_LINUX. Linux emulation is done with an LKM
(“Loadable Kernel Module”) so it can be installed on the fly
without having to reboot. You will need the following things in
your startup files, however:In /etc/rc.conf, you need the
following line:
linux_enable=YESThis, in turn, triggers the following action in
/etc/rc.i386:
# Start the Linux binary emulation if requested.
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
linux'; linux > /dev/null 2>&1
fiIf you want to verify it is running, modstat will do that:&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 4 f09e6000 001c f09ec010 1 linux_modHowever, there have been reports that this
fails on some 2.2-RELEASE and later systems. If for some reason
you cannot load the linux LKM, then statically link the emulator
in the kernel by adding
options LINUX
to your kernel config file. Then run config
and install the new kernel as described in the kernel configuration section.Installing Linux Runtime LibrariesInstalling using the linux_lib portMost linux applications use shared libraries, so you are
still not done until you install the shared libraries. It is
possible to do this by hand, however, it is vastly simpler to
just grab the linux_lib port:&prompt.root; cd /usr/ports/emulators/linux_lib
&prompt.root; make all installand you should have a working linux emulator. Legend (and
the mail archives :-) seems to hold that Linux emulation works
best with linux binaries linked against the ZMAGIC libraries;
QMAGIC libraries (such as those used in Slackware V2.0) may tend
to give the Linuxulator heartburn. Also, expect some programs to complain
about incorrect minor versions of the system libraries. In
general, however, this does not seem
to be a problem.Installing libraries manuallyIf you do not have the “ports” distribution, you can
install the libraries by hand instead. You will need the Linux
shared libraries that the program depends on and the runtime
linker. Also, you will need to create a "shadow root"
directory, /compat/linux, for Linux
libraries on your FreeBSD system. Any shared libraries opened
by Linux programs run under FreeBSD will look in this tree
first. So, if a Linux program loads, for example,
/lib/libc.so, FreeBSD will first try to
open /compat/linux/lib/libc.so, and if that
does not exist then it will try
/lib/libc.so. Shared libraries should be
installed in the shadow tree
/compat/linux/lib rather than the paths
that the Linux ld.so reports.FreeBSD-2.2-RELEASE and later works slightly differently
with respect to /compat/linux: all files, not just
libraries, are searched for from the “shadow root”
/compat/linux.Generally, you will need to look for the shared libraries
that Linux binaries depend on only the first few times that you
install a Linux program on your FreeBSD system. After a while,
you will have a sufficient set of Linux shared libraries on your
system to be able to run newly imported Linux binaries without
any extra work.How to install additional shared librariesWhat if you install the linux_lib port and your application
still complains about missing shared libraries? How do you know
which shared libraries Linux binaries need, and where to get
them? Basically, there are 2 possibilities (when following these
instructions: you will need to be root on your FreeBSD system to
do the necessary installation steps).If you have access to a Linux system, see what shared
libraries the application needs, and copy them to your FreeBSD system.
Example: you have just ftp'ed the Linux binary of Doom. Put it
on the Linux system you have access to, and check which shared
libraries it needs by running ldd linuxxdoom:&prompt.user; ldd linuxxdoom
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29You would need to get all the files from the last column,
and put them under /compat/linux, with the
names in the first column as symbolic links pointing to them.
This means you eventually have these files on your FreeBSD
system:/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29Note that if you already have a Linux shared library with
a matching major revision number to the first column of the
ldd output, you will not need to copy the file named in the
last column to your system, the one you already have should
work. It is advisable to copy the shared library anyway if it
is a newer version, though. You can remove the old one, as
long as you make the symbolic link point to the new one. So,
if you have these libraries on your system:/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27and you find a new binary that claims to require a later
version according to the output of ldd:libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29If it is only one or two versions out of date in the in
the trailing digit then do not worry about copying
/lib/libc.so.4.6.29 too, because the
program should work fine with the slightly older version.
However, if you like you can decide to replace the
libc.so anyway, and that should leave you
with:/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29The symbolic link mechanism is only
needed for Linux binaries. The FreeBSD runtime linker takes
care of looking for matching major revision numbers itself and
you do not need to worry about it.Configuring the ld.so — for FreeBSD
2.2-RELEASE and laterThis section applies only to FreeBSD 2.2-RELEASE and later.
Those running 2.1-STABLE should skip this section.Finally, if you run FreeBSD 2.2-RELEASE you must make sure
that you have the Linux runtime linker and its config files on
your system. You should copy these files from the Linux system
to their appropriate place on your FreeBSD system (to the
/compat/linux tree):/compat/linux/lib/ld.so
/compat/linux/etc/ld.so.configIf you do not have access to a Linux system, you should get
the extra files you need from various ftp sites. Information on
where to look for the various files is appended below. For now,
let us assume you know where to get the files.Retrieve the following files (all from the same ftp site to
avoid any version mismatches), and install them under
/compat/linux (i.e.
/foo/bar is installed as
/compat/linux/foo/bar):/sbin/ldconfig
/usr/bin/ldd
/lib/libc.so.x.y.z
/lib/ld.soldconfig and ldd do not necessarily need to be under
/compat/linux; you can install them
elsewhere in the system too. Just make sure they do not conflict
with their FreeBSD counterparts. A good idea would be to install
them in /usr/local/bin as ldconfig-linux
and ldd-linux.Create the file
/compat/linux/etc/ld.so.conf, containing
the directories in which the Linux runtime linker should look
for shared libs. It is a plain text file, containing a directory
name on each line. /lib and
/usr/lib are standard, you could add the
following:
/usr/X11/lib
/usr/local/libWhen a linux binary opens a library such as
/lib/libc.so the emulator maps the name to
/compat/linux/lib/libc.so internally. All
linux libraries should be installed under /compat/linux (e.g.
/compat/linux/lib/libc.so,
/compat/linux/usr/X11/lib/libX11.so, etc.)
in order for the emulator to find them.Those running FreeBSD 2.2-RELEASE should run the Linux
ldconfig program.&prompt.root cd /compat/linux/lib
&prompt.root; /compat/linux/sbin/ldconfigldconfig is statically linked, so it does not need any
shared libraries to run. It creates the file
/compat/linux/etc/ld.so.cache which
contains the names of all the shared libraries and should be
rerun to recreate this file whenever you install additional
shared libraries.On 2.1-STABLE do not install
/compat/linux/etc/ld.so.cache or run
ldconfig; in 2.1-STABLE the syscalls are implemented differently
and ldconfig is not needed or used.You should now be set up for Linux binaries which only need
a shared libc. You can test this by running the Linux ldd on
itself. Supposing that you have it installed as ldd-linux, it
should produce something like:&prompt.root; ldd-linux `which ldd-linux`
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29This being done, you are ready to install new Linux
binaries. Whenever you install a new Linux program, you should
check if it needs shared libraries, and if so, whether you have
them installed in the /compat/linux tree.
To do this, you run the Linux version ldd on the new program,
and watch its output. ldd (see also the manual page for ldd1)
will print a list of shared libraries that the program depends
on, in the form majorname (jumpversion) => fullname.If it prints not found instead of fullname it means that
you need an extra library. The library needed is shown in
majorname and will be of the form libXXXX.so.N. You will need to
find a libXXXX.so.N.mm on a Linux ftp site, and install it on
your system. The XXXX (name) and N (major revision number)
should match; the minor number(s) mm are less important, though
it is advised to take the most recent version.Installing Linux ELF binariesELF binaries sometimes require an extra step of
“branding”. If you attempt to run an unbranded ELF binary,
you will get an error message like the following;&prompt.user; ./my-linux-elf-binary
ELF binary type not known
AbortTo help the FreeBSD kernel distinguish between a FreeBSD ELF
- binary from a Linux one, use the
+ binary from a Linux binary, use the brandelf1 utility.&prompt.user; brandelf -t Linux my-linux-elf-binaryThe GNU toolchain now places the appropriate branding information
into ELF binaries automatically, so you should be needing to do this
step increasingly rarely in future.Configuring the host name resolverIf DNS does not work or you get the messages
resolv+: "bind" is an invalid keyword resolv+:
"hosts" is an invalid keyword
then you need to configure a
/compat/linux/etc/host.conf file containing:
order hosts, bind
multi on
where the order here specifies that
/etc/hosts is searched first and DNS is
searched second. When
/compat/linux/etc/host.conf is not installed
linux applications find FreeBSD's
/etc/host.conf and complain about the
incompatible FreeBSD syntax. You should remove bind if you
have not configured a name-server using the
/etc/resolv.conf file.Lastly, those who run 2.1-STABLE need to set an the
RESOLV_HOST_CONF environment variable so that applications will
know how to search the host tables. If you run FreeBSD
2.2-RELEASE or later, you can skip this. For the
/bin/csh shell use:&prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.confFor /bin/sh use:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFFinding the necessary filesThe information below is valid as of the time this document
was written, but certain details such as names of ftp sites,
directories and distribution names may have changed by the time
you read this.Linux is distributed by several groups that make their own set
of binaries that they distribute. Each distribution has its own
name, like “Slackware” or “Yggdrasil”. The distributions are
available on a lot of ftp sites. Sometimes the files are unpacked,
and you can get the individual files you need, but mostly they are
stored in distribution sets, usually consisting of subdirectories
with gzipped tar files in them. The primary ftp sites for the
distributions are:sunsite.unc.edu:/pub/Linux/distributionstsx-11.mit.edu:/pub/linux/distributionsSome European mirrors:ftp.luth.se:/pub/linux/distributionsftp.demon.co.uk:/pub/unix/linuxsrc.doc.ic.ac.uk:/packages/linux/distributionsFor simplicity, let us concentrate on Slackware here. This
distribution consists of a number of subdirectories, containing
separate packages. Normally, they are controlled by an install
program, but you can retrieve files “by hand” too. First of all,
you will need to look in the contents subdir of the
distribution. You will find a lot of small text files here
describing the contents of the separate packages. The fastest way
to look something up is to retrieve all the files in the contents
subdirectory, and grep through them for the file you need. Here is
an example of a list of files that you might need, and in which
contents-file you will find it by grepping through them:LibraryPackageld.soldso
ldconfigldso lddldso
libc.so.4shlibs libX11.so.6.0xf_lib
libXt.so.6.0xf_lib
libX11.so.3oldlibs
libXt.so.3oldlibs
So, in this case, you will need the packages ldso, shlibs,
xf_lib and oldlibs. In each of the contents-files for these
packages, look for a line saying PACKAGE LOCATION, it will
tell you on which “disk” the package is, in our case it will tell
us in which subdirectory we need to look. For our example, we
would find the following locations:PackageLocationldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 The locations called “diskXX” refer to the slakware/XX
subdirectories of the distribution, others may be found in the
contrib subdirectory. In this case, we
could now retrieve the packages we need by retrieving the
following files (relative to the root of the Slackware
distribution tree):slakware/a2/ldso.tgzslakware/a2/shlibs.tgzslakware/x6/oldlibs/tgzslakware/x9/xf_lib.tgzExtract the files from these gzipped tarfiles in your
/compat/linux directory (possibly omitting or
afterwards removing files you do not need), and you are
done.See also:ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README and /usr/src/sys/i386/ibcs2/README.iBCS2How to Install Mathematica on FreeBSDContributed by &a.rich; and
&a.chuck;This document shows how to install the Linux binary distribution
of Mathematica 2.2 on FreeBSD 2.1.Mathematica supports Linux but not FreeBSD as it stands. So
once you have configured your system for Linux compatibility you
have most of what you need to run Mathematica.For those who already have the student edition of Mathematica
for DOS the cost of upgrading to the Linux version at the time this
was written, March 1996, was $45.00. It can be ordered directly
from Wolfram at (217) 398-6500 and paid for by credit card.Unpacking the Mathematica distributionThe binaries are currently distributed by Wolfram on CDROM.
The CDROM has about a dozen tar files, each of which is a binary
distribution for one of the supported architectures. The one for
Linux is named LINUX.TAR. You can, for
example, unpack this into
/usr/local/Mathematica:&prompt.root; cd /usr/local
&prompt.root; mkdir Mathematica
&prompt.root; cd Mathematica
&prompt.root; tar -xvf /cdrom/LINUX.TARObtaining your Mathematica PasswordBefore you can run Mathematica you will have to obtain a
password from Wolfram that corresponds to your “machine
ID”.Once you have installed the linux compatibility runtime
libraries and unpacked the mathematica you can obtain the “machine
ID” by running the program mathinfo in the Install directory.&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; mathinfo
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
richc.isdn.bcm.tmc.edu 9845-03452-90255So, for example, the “machine ID” of richc is
9845-03452-90255. You can ignore the message about the ioctl
that is not implemented. It will not prevent Mathematica from
running in any way and you can safely ignore it, though you will
see the message every time you run Mathematica.When you register with Wolfram, either by email, phone or fax,
you will give them the “machine ID” and they will respond with a
corresponding password consisting of groups of numbers. You need
to add them both along with the machine name and license number in
your mathpass file.You can do this by invoking:&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; math.installIt will ask you to enter your license number
and the Wolfram supplied password. If you get them mixed up or
for some reason the math.install fails, that is OK; you can simply
edit the file mathpass in this same directory to correct the
info manually.After getting past the password, math.install will ask you if
you accept the install defaults provided, or if you want to use
your own. If you are like us and distrust all install programs,
you probably want to specify the actual directories. Beware.
Although the math.install program asks you to specify directories,
it will not create them for you, so you should perhaps have a
second window open with another shell so that you can create them
before you give them to the install program. Or, if it fails, you
can create the directories and then restart the math.install
program. The directories we chose to create beforehand and
specify to math.install were:/usr/local/Mathematica/binfor binaries/usr/local/Mathematica/man/man1for man pages/usr/local/Mathematica/lib/X11for the XKeysymb fileYou can also tell it to use
/tmp/math.record for the system record file,
where it puts logs of sessions. After this math.install will
continue on to unpacking things and placing everything where it
should go.The Mathematica Notebook feature is included separately, as
the X Front End, and you have to install it separately. To get the
X Front End stuff correctly installed, cd into the
/usr/local/Mathematica/FrontEnd directory and
execute the xfe.install shell script. You will have to tell it
where to put things, but you do not have to create any directories
because it will use the same directories that had been created for
math.install. When it finishes, there should be a new shell script
in /usr/local/Mathematica/bin called
mathematica.Lastly, you need to modify each of the shell scripts that
Mathematica has installed. At the beginning of every shell script
in /usr/local/Mathematica/bin add the
following line:&prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDBThis tells Mathematica were to find its own
version of the key mapping file XKeysymDB.
Without this you will get pages of error messages about missing
key mappings.On 2.1-STABLE you need to add the following as well:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFThis tells Mathematica to use the linux version
of host.conf. This file has a different syntax from FreeBSD's
host.conf, so you will get an error message about
/etc/host.conf if you leave this out.You might also want to modify your
/etc/manpath.config file to read the new man
directory, and you may need to edit your
~/.cshrc file to add
/usr/local/Mathematica/bin to your
path.That is about all it takes. With this you should be able to
type mathematica and get a really slick looking Mathematica
Notebook screen up. Mathematica has included the Motif user
interfaces, but it is compiled in statically, so you do not need
the Motif libraries. Good luck doing this yourself!BugsThe Notebook front end is known to hang sometimes when reading
notebook files with an error messages similar to:File .../Untitled-1.mb appears to be broken for OMPR.257.0We have not found the cause for this, but it only affects the
Notebook's X Window front end, not the mathematica engine itself.
So the command line interface invoked by 'math' is unaffected by
this bug.AcknowledgmentsA well-deserved thanks should go to &a.sos; and &a.peter; who
made linux emulation what it is today, and Michael Smith who drove
these two guys like dogs to get it to the point where it runs
Linux binaries better than linux! :-)
diff --git a/en_US.ISO8859-1/books/handbook/mail/chapter.sgml b/en_US.ISO8859-1/books/handbook/mail/chapter.sgml
index 18b2d73610..189309586a 100644
--- a/en_US.ISO8859-1/books/handbook/mail/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/mail/chapter.sgml
@@ -1,593 +1,593 @@
Electronic MailContributed by &a.wlloyd;.Electronic Mail configuration is the subject of many System Administration books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.Some parts of E-Mail configuration are controlled in the Domain
Name System (DNS). If you are going to run your own own DNS server
check out /etc/namedb and man -k named for more information.Basic InformationThese are the major programs involved in an E-Mail exchange. A
“mailhost” is a server that is
responsible for delivering and receiving all email for your host,
and possibly your network.User programThis is a program like elm, pine,
mail, or something more sophisticated like a WWW
browser. This program will simply pass off all e-mail
transactions to the local “mailhost” ,
either by calling sendmail or
delivering it over TCP.Mailhost Server DaemonUsually this program is sendmail or
smail running in the background. Turn it off or
change the command line options in
/etc/rc.conf (or, prior to FreeBSD 2.2.2,
/etc/sysconfig). It is best to leave it on,
unless you have a specific reason to want it off. Example: You
are building a Firewall.You should be aware that sendmail is a potential weak link in a
secure site. Some versions of sendmail have known security
problems.sendmail does two jobs. It looks after delivering
and receiving mail.If sendmail
needs to deliver mail off your site it will look up in
the DNS to determine the actual host that will receive mail for
the destination.If it is acting as a delivery agent sendmail will take the message from the
local queue and deliver it across the Internet to another sendmail
on the receivers computer.DNS — Name ServiceThe Domain Name System and its daemon named, contain the database mapping
hostname to IP address, and hostname to mailhost. The IP address
is specified in an A record. The MX record specifies the
mailhost that will receive mail for you. If you do not have a
MX record mail for your hostname, the mail will be delivered to
your host directly.Unless you are running your own DNS server, you will not be
able to change any information in the DNS yourself. If you are
using an Internet Provider, speak to them.POP ServersThis program gets the mail from your mailbox and gives it to
your browser. If you want to run a POP server on your computer,
you will need to do 2 things.Get pop software from the Ports collection that
can be found in /usr/ports or packages
collection. This handbook section has a complete reference
on the Ports system.Modify /etc/inetd.conf
to load the POP server.The pop program will have instructions with it. Read
them.ConfigurationBasicAs your FreeBSD system comes “out of the box”[TM], you should
be able to send E-mail to external hosts as long as you have
/etc/resolv.conf setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods:Run a name server (man -k named) and have your own domain
smallminingco.com Get mail delivered to the current DNS name for your host.
Ie: dorm6.ahouse.school.edu No matter what option you choose, to have mail delivered
directly to your host, you must be a full Internet host. You must
have a permanent IP address. IE: NO dynamic PPP. If you are
behind a firewall, the firewall must be passing on smtp traffic to
you. From /etc/services:smtp 25/tcp mail #Simple Mail TransferIf you
want to receive mail at your host itself, you must make sure that
the DNS MX entry points to your host address, or there is no MX
entry for your DNS name.Try this:&prompt.root; hostname
newbsdbox.freebsd.org
&prompt.root; host newbsdbox.freebsd.org
newbsdbox.freebsd.org has address 204.216.27.xxIf that is all that comes out for your machine, mail directory
to root@newbsdbox.freebsd.org
will work no problems.If instead, you have this:&prompt.root; host newbsdbox.freebsd.org
newbsdbox.FreeBSD.org has address 204.216.27.xx
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.orgAll mail sent to your host
directly will end up on freefall, under the same username.This information is setup in your domain name server. This
should be the same host that is listed as your primary nameserver
in /etc/resolv.confThe DNS record that carries mail routing information is the
Mail eXchange entry. If no MX entry exists, mail will be
delivered directly to the host by way of the Address
record.The MX entry for freefall.freebsd.org at one time.
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall HINFO Pentium FreeBSD
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com
freefall A 204.216.27.xx
freefall CNAME www.FreeBSD.orgfreefall has many MX entries. The lowest MX number gets the
mail in the end. The others will queue mail temporarily, if
freefall is busy or down.Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other
friendly site can provide this service.dig, nslookup,
and host are your friends.Mail for your Domain (Network).To setup up a network mailhost, you need to direct the mail
from arriving at all the workstations. In other words, you want to
hijack all mail for *.smallminingco.com
and divert it to one machine, your “mailhost”.The network users on their workstations will most likely pick
up their mail over POP or telnet.A user account with the same username should exist on both
machines. Please use adduser to do
this as required. If you set the shell to
/nonexistent
the user will not be allowed to login.The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS
(ie BIND, named). Please refer to a Networking book for in-depth
information.You basically need to add these lines in your DNS server.
pc24.smallminingco.com A xxx.xxx.xxx.xxx ; Workstation ip
MX 10 smtp.smallminingco.com ; Your mailhostYou cannot do this yourself unless you are running a DNS
server. If you do not want to run a DNS server, get somebody else
like your Internet Provider to do it.This will redirect mail for the workstation to the Mail
eXchange host. It does not matter what machine the A record
points to, the mail will be sent to the MX host.This feature is used to implement Virtual E-Mail Hosting.ExampleI have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make
an entry in your DNS server like:
foo.bar MX 10 smtp.smalliap.com ; your mailhostThe A record is not needed if you only
want E-Mail for the domain. IE: Don't expect ping foo.bar
to work unless an Address record for foo.bar
exists as well.On the mailhost that actually accepts mail for final delivery
to a mailbox, sendmail must be told what hosts it will be
accepting mail for.Add pc24.smallminingco.com to /etc/sendmail.cw (if you are
using FEATURE(use_cw_file)), or add a Cw myhost.smalliap.com
line to /etc/sendmail.cfIf you plan on doing anything serious with sendmail you should install the sendmail
source. The source has plenty of documentation with it. You will
find information on getting sendmail
source from the UUCP
information.Setting up UUCP.Stolen from the FAQ.The sendmail configuration that ships with FreeBSD is suited
for sites that connect directly to the Internet. Sites that wish
to exchange their mail via UUCP must install another sendmail
configuration file.Tweaking /etc/sendmail.cf manually is
considered something for purists. Sendmail version 8 comes with a
new approach of generating config files via some m4 preprocessing, where the actual
hand-crafted configuration is on a higher abstraction level. You
should use the configuration files under
/usr/src/usr.sbin/sendmail/cf.If you did not install your system with full sources, the
sendmail config stuff has been broken out into a separate source
distribution tarball just for you. Assuming you have your CD-ROM
mounted, do:&prompt.root; cd /usr/src
&prompt.root; tar -xvzf /cdrom/dists/src/ssmailcf.aaDo not panic, this is only a few hundred kilobytes in size.
The file README in the cf directory can serve as a basic
introduction to m4 configuration.For UUCP delivery, you are best advised to use the
mailertable feature. This constitutes a
database that sendmail can use to base its routing decision
upon.First, you have to create your .mc file.
The directory
/usr/src/usr.sbin/sendmail/cf/cf is the home
of these files. Look around, there are already a few examples.
Assuming you have named your file foo.mc, all
you need to do in order to convert it into a valid
sendmail.cf is:&prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf
&prompt.root; make foo.cfIf you don't have a /usr/obj hiearchy,
then:&prompt.root; cp foo.cf /etc/sendmail.cfOtherwise:&prompt.root; cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cfA typical .mc file might look
like:
include(`../m4/cf.m4')
VERSIONID(`Your version number')
OSTYPE(bsd4.4)
FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)
define(`UUCP_RELAY', your.uucp.relay)
define(`UUCP_MAX_SIZE', 200000)
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw your.alias.host.name
Cw youruucpnodename.UUCPThe nodns and
nocanonify features will prevent any usage of
the DNS during mail delivery. The UUCP_RELAY
clause is needed for bizarre reasons, do not ask. Simply put an
Internet hostname there that is able to handle .UUCP pseudo-domain
addresses; most likely, you will enter the mail relay of your ISP
there.Once you have this, you need this file called
/etc/mailertable. A typical example of this
gender again:
#
# makemap hash /etc/mailertable.db < /etc/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1 horus.UUCP
uucp-dom:horus if-bus.UUCP
uucp-dom:if-bus . uucp-dom:saxAs you can see, this is part of a real-life file. The first
three lines handle special cases where domain-addressed mail
should not be sent out to the default route, but instead to some
UUCP neighbor in order to “shortcut” the delivery path. The
next line handles mail to the local Ethernet domain that can be
delivered using SMTP. Finally, the UUCP neighbors are mentioned
in the .UUCP pseudo-domain notation, to allow for a
uucp-neighbor!recipient override of the default rules. The
last line is always a single dot, matching everything else, with
UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
uucp-dom: keyword must be valid UUCP
neighbors, as you can verify using the command uuname.As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish
this is best placed as a comment at the top of the mailertable.
You always have to execute this command each time you change your
mailertable.Final hint: if you are uncertain whether some particular mail
routing would work, remember the option to
sendmail. It starts sendmail
in “address test
mode”; simply enter 0, followed by the address
you wish to test for the mail routing. The last line tells you
the used internal mail agent, the destination host this agent will
be called with, and the (possibly translated) address. Leave this
mode by typing Control-D.&prompt.user; sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>0 foo@interface-business.de
rewrite: ruleset 0 input: foo @ interface-business . de
…
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . deFAQMigration from FAQ.Why do I have to use the FQDN for hosts on my site?You will probably find that the host is actually in a
different domain; for example, if you are in foo.bar.edu and you
wish to reach a host called mumble in the bar.edu domain, you
will have to refer to it by the fully-qualified domain name,
mumble.bar.edu, instead of just mumble.Traditionally, this was allowed by BSD BIND resolvers. However
the current version of BIND that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host mumble must either
be found as mumble.foo.bar.edu, or
it will be searched for in the root domain.This is different from the previous behavior, where the search
continued across mumble.bar.edu,
and mumble.edu. Have a look at
RFC 1535 for why this was considered bad practice, or even a
security hole.As a good workaround, you can place the line
search foo.bar.edu bar.edu
instead of the previous
domain foo.bar.edu
into your /etc/resolv.conf. However,
make sure that the search order does not go beyond the “boundary
between local and public administration”, as RFC 1535 calls
it.Sendmail says mail loops back to myselfThis is answered in the sendmail FAQ as follows:
* I am getting "Local configuration error" messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 <user@domain.net>... Local configuration error
How can I solve this problem?
You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine does not recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
to /etc/sendmail.cf.The sendmail FAQ is in
/usr/src/usr.sbin/sendmail and is recommended
reading if you want to do any “tweaking” of your mail
setup.How can I do E-Mail with a dialup PPP host?You want to connect a FreeBSD box on a lan, to the Internet.
The FreeBSD box will be a mail gateway for the lan. The PPP
connection is non-dedicated.There are at least two way to do this.The other is to use UUCP.The key is to get a Internet site to provide secondary MX
services for your domain. For example:
bigco.com. MX 10 bigco.com.
MX 20 smalliap.com.Only one host should be specified as the final recipient ( add
Cw bigco.com in /etc/sendmail.cf on
bigco.com).When the senders sendmail is trying to deliver the mail it
will try to connect to you over the modem link. It will most
likely time out because you are not online. sendmail will
automatically deliver it to the secondary MX site, ie your
Internet provider. The secondary MX site will try every
(sendmail_flags = "-bd -q15m" in
/etc/rc.conf ) 15 minutes to connect to your
host to deliver the mail to the primary MX site.
- You might wat to use something like this as a login script.
+ You might want to use something like this as a login script.
#!/bin/sh
# Put me in /usr/local/bin/pppbigco
( sleep 60 ; /usr/sbin/sendmail -q ) &
/usr/sbin/ppp -direct pppbigcoIf you are going to create a separate
login script for a user you could use sendmail
-qRbigco.com instead in the script above. This will
force all mail in your queue for bigco.com to be processed
immediately.A further refinement of the situation is as follows.Message stolen from the freebsd-isp mailing list.
> we provide the secondary mx for a customer. The customer connects to
> our services several times a day automatically to get the mails to
> his primary mx (We do not call his site when a mail for his domains
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
> moment he has to stay 30 minutes online to be sure that all mail is
> gone to the primary mx.
>
> Is there a command that would initiate sendmail to send all the mails
> now? The user has not root-privileges on our machine of course.
In the 'privacy flags' section of sendmail.cf, there is a definition
Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
customers like this, and we have defined:
# If we are the best MX for a host, try directly instead of generating
# local config error.
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
"hosts", so you need to get your customer to name their mail machine
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
an A record in the DNS for "customer.com".
diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
index 0f4423b959..5f1a569539 100644
--- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
@@ -1,1440 +1,1443 @@
Obtaining FreeBSDCD-ROM PublishersFreeBSD is available on CD-ROM from Walnut Creek CDROM:
Walnut Creek CDROM4041 Pike Lane, Suite FConcordCA, 94520USA
Phone: +1 925 674-0783
Fax: +1 925 674-0821
Email: info@cdrom.com
WWW: http://www.cdrom.com/FTP SitesThe official sources for FreeBSD are available via anonymous FTP
from:
ftp://ftp.FreeBSD.ORG/pub/FreeBSD.
The FreeBSD mirror
sites database is more accurate than the mirror listing in the
handbook, as it gets its information form the DNS rather than relying
on static lists of hosts.Additionally, FreeBSD is available via anonymous FTP from the
following mirror sites. If you choose to obtain FreeBSD via
anonymous FTP, please try to use a site near you.Argentina,
Australia,
Brazil,
Canada,
Czech Republic,
Denmark,
Estonia,
Spain,
Finland,
France,
Germany,
Hong Kong,
Ireland,
Israel,
Japan,
Korea,
Netherlands,
Poland,
Portugal,
Russia,
South Africa,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
Ukraine,
UK,
USA.ArgentinaIn case of problems, please contact the hostmaster hostmaster@ar.FreeBSD.ORG
for this domain.ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster hostmaster@au.FreeBSD.ORG
for this domain.ftp://ftp.au.FreeBSD.ORG/pub/FreeBSDftp://ftp2.au.FreeBSD.ORG/pub/FreeBSDftp://ftp3.au.FreeBSD.ORG/pub/FreeBSDftp://ftp4.au.FreeBSD.ORG/pub/FreeBSDBrazilIn case of problems, please contact the hostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDftp://ftp2.br.FreeBSD.ORG/pub/FreeBSDftp://ftp3.br.FreeBSD.ORG/pub/FreeBSDftp://ftp4.br.FreeBSD.ORG/pub/FreeBSDftp://ftp5.br.FreeBSD.ORG/pub/FreeBSDftp://ftp6.br.FreeBSD.ORG/pub/FreeBSDftp://ftp7.br.FreeBSD.ORG/pub/FreeBSDCanadaIn case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.ORG
for this domain.ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSDCzech Republicftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.DenmarkIn case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.ORG
for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.ORG
for this domain.ftp://ftp.ee.freebsd.ORG/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.ORG
for this domain.ftp://ftp.fi.freebsd.ORG/pub/FreeBSDFranceftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.GermanyIn case of problems, please contact the hostmaster hostmaster@de.FreeBSD.ORG
for this domain.ftp://ftp.de.FreeBSD.ORG/pub/FreeBSDftp://ftp2.de.FreeBSD.ORG/pub/FreeBSDftp://ftp3.de.FreeBSD.ORG/pub/FreeBSDftp://ftp4.de.FreeBSD.ORG/pub/FreeBSDftp://ftp5.de.FreeBSD.ORG/pub/FreeBSDftp://ftp6.de.FreeBSD.ORG/pub/FreeBSDftp://ftp7.de.FreeBSD.ORG/pub/FreeBSDHong Kongftp://ftp.hk.super.net/pub/FreeBSD Contact: ftp-admin@HK.Super.NET.IrelandIn case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.ORG
for this domain.ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster hostmaster@il.FreeBSD.ORG
for this domain.ftp://ftp.il.FreeBSD.ORG/pub/FreeBSDftp://ftp2.il.FreeBSD.ORG/pub/FreeBSDJapanIn case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.ORG
for this domain.ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSDKoreaIn case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.ORG
for this domain.ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp3.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp4.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp5.kr.FreeBSD.ORG/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.ORG
for this domain.ftp://ftp.nl.freebsd.ORG/pub/FreeBSDPolandIn case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.ORG
for this domain.ftp://ftp.pl.freebsd.ORG/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.ORG
for this domain.ftp://ftp.pt.freebsd.org/pub/FreeBSDftp://ftp2.pt.freebsd.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.ORG
for this domain.ftp://ftp.ru.freebsd.org/pub/FreeBSDftp://ftp2.ru.freebsd.org/pub/FreeBSDftp://ftp3.ru.freebsd.org/pub/FreeBSDftp://ftp4.ru.freebsd.org/pub/FreeBSDSouth AfricaIn case of problems, please contact the hostmaster hostmaster@za.FreeBSD.ORG
for this domain.ftp://ftp.za.FreeBSD.ORG/pub/FreeBSDftp://ftp2.za.FreeBSD.ORG/pub/FreeBSDftp://ftp3.za.FreeBSD.ORG/pub/FreeBSDSlovak RepublicIn case of problems, please contact the hostmaster
hostmaster@sk.FreeBSD.ORG for this domain.ftp://ftp.sk.freebsd.ORG/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster hostmaster@si.FreeBSD.ORG
for this domain.ftp://ftp.si.freebsd.ORG/pub/FreeBSDSpainIn case of problems, please contact the hostmaster
hostmaster@es.FreeBSD.ORG for this domain.ftp://ftp.es.freebsd.ORG/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster hostmaster@se.FreeBSD.ORG
for this domain.ftp://ftp.se.freebsd.ORG/pub/FreeBSDftp://ftp2.se.freebsd.ORG/pub/FreeBSDftp://ftp3.se.freebsd.ORG/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.ORG
for this domain.ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSDThailandftp://ftp.nectec.or.th/pub/FreeBSD Contact: ftpadmin@ftp.nectec.or.th.Ukraineftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: archer@lucky.net.
+ URL="ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD">ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: freebsd-mnt@lucky.net.
UKIn case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.ORG
for this domain.ftp://ftp.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp2.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp3.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp4.uk.FreeBSD.ORG/pub/FreeBSDUSAIn case of problems, please contact the hostmaster hostmaster@FreeBSD.ORG for
this domain.ftp://ftp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.FreeBSD.ORG/pub/FreeBSDftp://ftp3.FreeBSD.ORG/pub/FreeBSDftp://ftp4.FreeBSD.ORG/pub/FreeBSDftp://ftp5.FreeBSD.ORG/pub/FreeBSDftp://ftp6.FreeBSD.ORG/pub/FreeBSDThe latest versions of export-restricted code for FreeBSD (2.0C
or later) (eBones and secure) are being made available at the
following locations. If you are outside the U.S. or Canada, please
get secure (DES) and eBones (Kerberos) from one of the following
foreign distribution sites:South AfricaHostmaster hostmaster@internat.FreeBSD.ORG for this domain.ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSDftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSDBrazilHostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.CTM SitesCTM/FreeBSD is available via
anonymous FTP from the following mirror sites. If you choose to
obtain CTM via anonymous FTP, please try to use a site near
you.In case of problems, please contact &a.phk;.California, Bay Area, official sourceftp://ftp.freebsd.org/pub/FreeBSD/CTMGermany, Trierftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTMSouth Africa, backup server for old
deltasftp://ftp.internat.freebsd.org/pub/FreeBSD/CTMTaiwan/R.O.C, Chiayiftp://ctm.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm2.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm3.tw.freebsd.org/pub/freebsd/CTMIf you did not find a mirror near to you or the mirror is
incomplete, try FTP
search at http://ftpsearch.ntnu.no/ftpsearch. FTP search is a great free archie server in Trondheim, Norway.CVSup SitesCVSup servers for FreeBSD are
running at the following sites:Argentinacvsup.ar.FreeBSD.ORG (maintainer msagre@cactus.fi.uba.ar)Australiacvsup.au.FreeBSD.ORG (maintainer dawes@physics.usyd.edu.au)Brazilcvsup.br.FreeBSD.ORG (maintainer cvsup@cvsup.br.freebsd.org)Canadacvsup.ca.FreeBSD.ORG (maintainer james@ican.net)Denmarkcvsup.dk.FreeBSD.ORG (maintainer
jesper@skriver.dk)Estoniacvsup.ee.FreeBSD.ORG (maintainer taavi@uninet.ee)Finlandcvsup.fi.FreeBSD.ORG (maintainer count@key.sms.fi)Germanycvsup.de.FreeBSD.ORG (maintainer wosch@freebsd.org)cvsup2.de.FreeBSD.ORG (maintainer petzi@freebsd.org)cvsup3.de.FreeBSD.ORG (maintainer ag@leo.org)Icelandcvsup.is.FreeBSD.ORG (maintainer
adam@veda.is)Japancvsup.jp.FreeBSD.ORG (maintainer simokawa@sat.t.u-tokyo.ac.jp)cvsup2.jp.FreeBSD.ORG (maintainer max@FreeBSD.ORG)cvsup3.jp.FreeBSD.ORG (maintainer
shige@cin.nihon-u.ac.jp)cvsup4.jp.FreeBSD.ORG (maintainer
cvsup-admin@ftp.media.kyoto-u.ac.jp)cvsup5.jp.FreeBSD.ORG (maintainer
cvsup@imasy.or.jp)Netherlandscvsup.nl.FreeBSD.ORG (maintainer xaa@xaa.iae.nl)Norwaycvsup.no.FreeBSD.ORG (maintainer Tor.Egge@idt.ntnu.no)Polandcvsup.pl.FreeBSD.ORG (maintainer Mariusz@kam.pl)Russiacvsup.ru.FreeBSD.ORG (maintainer mishania@demos.su)Swedencvsup.se.FreeBSD.ORG (maintainer pantzer@ludd.luth.se)Slovak Republiccvsup.sk.FreeBSD.ORG (maintainer
tps@tps.sk)cvsup2.sk.FreeBSD.ORG (maintainer
tps@tps.sk)South Africacvsup.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)cvsup2.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)Taiwancvsup.tw.FreeBSD.ORG (maintainer jdli@freebsd.csie.nctu.edu.tw)Ukraine
- cvsup2.ua.FreeBSD.ORG (maintainer archer@lucky.net)
+ cvsup2.ua.FreeBSD.ORG (maintainer freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer joe@pavilion.net)USAcvsup.FreeBSD.ORG (maintainer skynyrd@opus.cts.cwu.edu)cvsup2.FreeBSD.ORG (maintainer jdp@FreeBSD.ORG)cvsup3.FreeBSD.ORG (maintainer wollman@FreeBSD.ORG)
+
+ cvsup4.FreeBSD.ORG (maintainer shmit@rcn.com)
+ The export-restricted code for FreeBSD (eBones and secure) is
available via CVSup at the following international repository.
Please use this site to get the export-restricted code, if you are
outside the USA or Canada.South Africacvsup.internat.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)The following CVSup site is especially designed for CTM users. Unlike the other CVSup mirrors,
it is kept up-to-date by CTM. That means if you CVSupcvs-all with release=cvs
from this site, you get a version of the repository (including the
inevitable .ctm_status file) which is
suitable for being updated using the CTMcvs-cur deltas. This allows users who track
the entire cvs-all tree to go from
CVSup to CTM without having to rebuild their repository from scratch
using a fresh CTM base delta.This special feature only works for the cvs-all distribution with
cvs as the release tag. CVSupping any other
distribution and/or release will get you the specified
distribution, but it will not be suitable for CTM updating.Because the current version of CTM does not preserve the
timestamps of files, the timestamps at this mirror site are not
the same as those at other mirror sites. Switching between this
site and other sites is not recommended. It will work correctly,
but will be somewhat inefficient.Germanyctm.FreeBSD.ORG (maintainer blank@fox.uni-trier.de)AFS SitesAFS servers for FreeBSD are running at the following sites;Swedenstacken.kth.se, Stacken
Computer Club, KTH, Sweden130.237.234.3, milko.stacken.kth.se130.237.234.43, hot.stacken.kth.se130.237.234.44, dog.stacken.kth.seMaintainer ftp@stacken.kth.se
diff --git a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
index cb1b9b9d1f..4323cc68e1 100644
--- a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
@@ -1,510 +1,579 @@
PGP keysIn case you need to verify a signature or send encrypted email to
one of the officers or core team members a number of keys are
provided here for your convenience.OfficersFreeBSD Security Officer security-officer@freebsd.org
FreeBSD Security Officer <security-officer@freebsd.org>
Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL
h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L
Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR
tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl
ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU
tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7
PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql
3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz
QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV
nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A
3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD
/REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb
5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS
9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B
sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P
BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT
0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx
ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD
ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO
v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1
lw==
=ipyA
-----END PGP PUBLIC KEY BLOCK-----&a.imp;
Warner Losh <imp@village.org>
aka <imp@freebsd.org>
Fingerprint = D4 31 FD B9 F7 90 17 E8 37 C5 E7 7F CF A6 C1 B9
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzDzTiAAAAEEAK8D7KWEbVFUrmlqhUEnAvphNIqHEbqqT8s+c5f5c2uHtlcH
V4mV2TlUaDSVBN4+/D70oHmZc4IgiQwMPCWRrSezg9z/MaKlWhaslc8YT6Xc1q+o
EP/fAdKUrq49H0QQbkQk6Ks5wKW6v9AOvdmsS6ZJEcet6d9G4dxynu/2qPVhAAUR
tCBNLiBXYXJuZXIgTG9zaCA8aW1wQHZpbGxhZ2Uub3JnPokAlQMFEDM/SK1VLh4u
c9KIpQEBFPsD/1n0YuuUPvD4CismZ9bx9M84y5sxLolgFEfP9Ux196ZSeaPpkA0g
C9YX/IyIy5VHh3372SDWN5iVSDYPwtCmZziwIV2YxzPtZw0nUu82P/Fn8ynlCSWB
5povLZmgrWijTJdnUWI0ApVBUTQoiW5MyrNN51H3HLWXGoXMgQFZXKWYiQCVAwUQ
MzmhkfUVW/uOVC1dAQG3+AP/T1HL/5EYF0ij0yQmNTzt1cLt0b1e3N3zN/wPFFWs
BfrQ+nsv1zw7cEgxLtktk73wBGM9jUIdJu8phgLtl5a0m9UjBq5oxrJaNJr6UTxN
a+sFkapTLT1g84UFUO/+8qRB12v+hZr2WeXMYjHAFUT18mp3xwjW9DUV+2fW1Wag
YDKJAJUDBRAzOYK1s1pi61mfMj0BARBbA/930CHswOF0HIr+4YYUs1ejDnZ2J3zn
icTZhl9uAfEQq++Xor1x476j67Z9fESxyHltUxCmwxsJ1uOJRwzjyEoMlyFrIN4C
dE0C8g8BF+sRTt7VLURLERvlBvFrVZueXSnXvmMoWFnqpSpt3EmN6TNaLe8Cm87a
k6EvQy0dpnkPKokAlQMFEDD9Lorccp7v9qj1YQEBrRUD/3N4cCMWjzsIFp2Vh9y+
RzUrblyF84tJyA7Rr1p+A7dxf7je3Zx5QMEXosWL1WGnS5vC9YH2WZwv6sCU61gU
rSy9z8KHlBEHh+Z6fdRMrjd9byPf+n3cktT0NhS23oXB1ZhNZcB2KKhVPlNctMqO
3gTYx+Nlo6xqjR+J2NnBYU8p =7fQV
-----END PGP PUBLIC KEY BLOCK-----Core Team members&a.asami;
Satoshi Asami <asami@cs.berkeley.edu>
aka <asami@FreeBSD.ORG>
Fingerprint = EB 3C 68 9E FB 6C EB 3F DB 2E 0F 10 8F CE 79 CA
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzPVyoQAAAEEAL7W+kipxB171Z4SVyyL9skaA7hG3eRsSOWk7lfvfUBLtPog
f3OKwrApoc/jwLf4+Qpdzv5DLEt/6Hd/clskhJ+q1gMNHyZ5ABmUxrTRRNvJMTrb
3fPU3oZj7sL/MyiFaT1zF8EaMP/iS2ZtcFsbYOqGeA8E/58uk4NA0SoeCNiJAAUR
tCVTYXRvc2hpIEFzYW1pIDxhc2FtaUBjcy5iZXJrZWxleS5lZHU+iQCVAwUQM/AT
+EqGN2HYnOMZAQF11QP/eSXb2FuTb1yX5yoo1Im8YnIk1SEgCGbyEbOMMBznVNDy
5g2TAD0ofLxPxy5Vodjg8rf+lfMVtO5amUH6aNcORXRncE83T10JmeM6JEp0T6jw
zOHKz8jRzygYLBayGsNIJ4BGxa4LeaGxJpO1ZEvRlNkPH/YEXK5oQmq9/DlrtYOJ
AEUDBRAz42JT8ng6GBbVvu0BAU8nAYCsJ8PiJpRUGlrz6rxjX8hqM1v3vqFHLcG+
G52nVMBSy+RZBgzsYIPwI5EZtWAKb22JAJUDBRAz4QBWdbtuOHaj97EBAaQPA/46
+NLUp+Wubl90JoonoXocwAg88tvAUVSzsxPXj0lvypAiSI2AJKsmn+5PuQ+/IoQy
lywRsxiQ5GD7C72SZ1yw2WI9DWFeAi+qa4b8n9fcLYrnHpyCY+zxEpu4pam8FJ7H
JocEUZz5HRoKKOLHErzXDiuTkkm72b1glmCqAQvnB4kAlQMFEDPZ3gyDQNEqHgjY
iQEBFfUEALu2C0uo+1Z7C5+xshWRYY5xNCzK20O6bANVJ+CO2fih96KhwsMof3lw
fDso5HJSwgFd8WT/sR+Wwzz6BAE5UtgsQq5GcsdYQuGI1yIlCYUpDp5sgswNm+OA
bX5a+r4F/ZJqrqT1J56Mer0VVsNfe5nIRsjd/rnFAFVfjcQtaQmjiQCVAwUQM9uV
mcdm8Q+/vPRJAQELHgP9GqNiMpLQlZig17fDnCJ73P0e5t/hRLFehZDlmEI2TK7j
Yeqbw078nZgyyuljZ7YsbstRIsWVCxobX5eH1kX+hIxuUqCAkCsWUY4abG89kHJr
XGQn6X1CX7xbZ+b6b9jLK+bJKFcLSfyqR3M2eCyscSiZYkWKQ5l3FYvbUzkeb6K0
IVNhdG9zaGkgQXNhbWkgPGFzYW1pQEZyZWVCU0QuT1JHPg==
=39SC
-----END PGP PUBLIC KEY BLOCK-----&a.jmb;
Jonathan M. Bresler <jmb@FreeBSD.org>
f16 Fingerprint16 = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNbtI
gAHbXdKX5jjdAQHamQP+OQr10QRknamIPmuHmFYJZ0jU9XPIvTTMuOiUYLcXlTdn
GyTUuzhbEywgtOldW2V5iA8platXThtqC68NsnN/xQfHA5xmFXVbayNKn8H5stDY
2s/4+CZ06mmJfqYmONF1RCbUk/M84rVT3Gn2tydsxFh4Pm32lf4WREZWRiLqmw+J
AJUDBRA0DfF99RVb+45ULV0BAcZ0BACCydiSUG1VR0a5DBcHdtin2iZMPsJUPRqJ
tWvP6VeI8OFpNWQ4LW6ETAvn35HxV2kCcQMyht1kMD+KEJz7r8Vb94TS7KtZnNvk
2D1XUx8Locj6xel5c/Lnzlnnp7Bp1XbJj2u/NzCaZQ0eYBdP/k7RLYBYHQQln5x7
BOuiRJNVU4kAlQMFEDQLcShVLh4uc9KIpQEBJv4D/3mDrD0MM9EYOVuyXik3UGVI
8quYNA9ErVcLdt10NjYc16VI2HOnYVgPRag3Wt7W8wlXShpokfC/vCNt7f5JgRf8
h2a1/MjQxtlD+4/Js8k7GLa53oLon6YQYk32IEKexoLPwIRO4L2BHWa3GzHJJSP2
aTR/Ep90/pLdAOu/oJDUiQCVAwUQMqyL0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz
2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyWCGw49XR/vPKYIJY9EYo4t49GIajRkISQ
NNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4dybo7oEKYMWWijQzGjqf2m8wf9OaaofE
KwBX6nxcRbKsxm/BVLKczGYl3XtjkcuJAJUDBRA1ol5TZWCprDT5+dUBATzXA/9h
/ZUuhoRKTWViaistGJfWi26FB/Km5nDQBr/Erw3XksQCMwTLyEugg6dahQ1u9Y5E
5tKPxbB69eF+7JXVHE/z3zizR6VL3sdRx74TPacPsdhZRjChEQc0htLLYAPkJrFP
VAzAlSlm7qd+MXf8fJovQs6xPtZJXukQukPNlhqZ94kAPwMFEDSH/kF4tXKgazlt
bxECfk4AoO+VaFVfguUkWX10pPSSfvPyPKqiAJ4xn8RSIe1ttmnqkkDMhLh00mKj
lLQuSm9uYXRoYW4gTS4gQnJlc2xlciA8Sm9uYXRoYW4uQnJlc2xlckBVU2kubmV0
PokAlQMFEDXbdSkB213Sl+Y43QEBV/4D/RLJNTrtAqJ1ATxXWv9g8Cr3/YF0GTmx
5dIrJOpBup7eSSmiM/BL9Is4YMsoVbXCI/8TqA67TMICvq35PZU4wboQB8DqBAr+
gQ8578M7Ekw1OAF6JXY6AF2P8k7hMcVBcVOACELPT/NyPNByG5QRDoNmlsokJaWU
/2ls4QSBZZlb
=zbCw
-----END PGP PUBLIC KEY BLOCK-----&a.ache;
Andrey A. Chernov <ache@FreeBSD.org>
aka <ache@nagual.pp.ru>
Key fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs
Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD
m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT
tCVBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucHAucnU+iQCVAwUQM2Ez
u+JgpPLZnQjrAQEyugP8DPnS8ixJ5OeuYgPFQf5sy6l+LrB6hyaS+lgsUPahWjNY
cnaDmfda/q/BV5d4+y5rlQe/pjnYG7/yQuAR3jhlXz8XDrqlBOnW9AtYjDt5rMfJ
aGFTGXAPGZ6k6zQZE0/YurT8ia3qjvuZm3Fw4NJrHRx7ETHRvVJDvxA6Ggsvmr20
JEFuZHJleSBBLiBDaGVybm92IDxhY2hlQEZyZWVCU0Qub3JnPokAlQMFEDR5uVbi
YKTy2Z0I6wEBLgED/2mn+hw4/3peLx0Sb9LNx//NfCCkVefSf2G9Qwhx6dvwbX7h
mFca97h7BQN4GubU1Z5Ffs6TeamSBrotBYGmOCwvJ6S9WigF9YHQIQ3B4LEjskAt
pcjU583y42zM11kkvEuQU2Gde61daIylJyOxsgpjSWpkxq50fgY2kLMfgl/ftCZB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuaWV0enNjaGUubmV0PokAlQMFEDR5svDi
YKTy2Z0I6wEBOTQD/0OTCAXIjuak363mjERvzSkVsNtIH9hA1l0w6Z95+iH0fHrW
xXKT0vBZE0y0Em+S3cotLL0bMmVE3F3D3GyxhBVmgzjyx0NYNoiQjYdi+6g/PV30
Cn4vOO6hBBpSyI6vY6qGNqcsawuRtHNvK/53MpOfKwSlICEBYQimcZhkci+EtCJB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJgpPLZ
nQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqKK8QY
rr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK/k7B
gI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFuZHJl
eSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+iQCV
AwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj4GPa
o3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI5apJ
mWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/osnzC
Cw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOvaoGr
anxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPriu8dI
rlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD7Hv8
vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZYMFO
DHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VSTGlh
Bhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+Mtun9
KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/YC3a
hs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1tGR3b
vz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwOTNQI
AOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fteFRkB
AWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96xnaa5
MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYiI0UA
Iwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAOz6qx
/IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBpYsfA
+6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzutZiM
1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cdiQCV
AwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgRsWFM
y9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8JkRv
Cn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6bLMV
HEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT1b14
5po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvlOm3R
rsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQPTi3
5SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qOx9Fw
erGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVjDHH5
+uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgbyldq6
EB33OunazFcfZFRIcXk1sfyLDvYE
=1ahV
-----END PGP PUBLIC KEY BLOCK-----&a.jkh;
Jordan K. Hubbard <jkh@FreeBSD.org>
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokBFQMFEDXCTXQM
j46yp4IfPQEBwO8IAIN0J09AXBf86dFUTFGcAMrEQqOF5IL+KGorAjzuYxERhKfD
ZV7jA+sCQqxkWfcVcE20kVyVYqzZIkio9a5zXP6TwA247JkPt54S1PmMDYHNlRIY
laXlNoji+4q3HP2DfHqXRT2859rYpm/fG/v6pWkos5voPKcZ2OFEp9W+Ap88oqw+
5rx4VetZNJq1Epmis4INj6XqNqj85+MOOIYE+f445ohDM6B/Mxazd6cHFGGIR+az
VjZ6lCDMLjzhB5+FqfrDLYuMjqkMTR5z9DL+psUvPlCkYbQ11NEWtEmiIWjUcNJN
GCxGzv5bXk0XPu3ADwbPkFE2usW1cSM7AQFiwuyJAJUDBRAxe+Q9a1pnjYGyp3kB
AV7XA/oCSL/Cc2USpQ2ckwkGpyvIkYBPszIcabSNJAzm2hsU9Qa6WOPxD8olDddB
uJNiW/gznPC4NsQ0N8Zr4IqRX/TTDVf04WhLmd8AN9SOrVv2q0BKgU6fLuk979tJ
utrewH6PR2qBOjAaR0FJNk4pcYAHeT+e7KaKy96YFvWKIyDvc4kAlQMFEDF8ldof
f6kIA1j8vQEBDH4D/0Zm0oNlpXrAE1EOFrmp43HURHbij8n0Gra1w9sbfo4PV+/H
U8ojTdWLy6r0+prH7NODCkgtIQNpqLuqM8PF2pPtUJj9HwTmSqfaT/LMztfPA6PQ
csyT7xxdXl0+4xTDl1avGSJfYsI8XCAy85cTs+PQwuyzugE/iykJO1Bnj/paiQCV
AwUQMXvlBvUVW/uOVC1dAQF2fQP/RfYC6RrpFTZHjo2qsUHSRk0vmsYfwG5NHP5y
oQBMsaQJeSckN4n2JOgR4T75U4vS62aFxgPLJP3lOHkU2Vc7xhAuBvsbGr5RP8c5
LvPOeUEyz6ZArp1KUHrtcM2iK1FBOmY4dOYphWyWMkDgYExabqlrAq7FKZftpq/C
BiMRuaw=
=C/Jw
-----END PGP PUBLIC KEY BLOCK-----&a.phk;
Poul-Henning Kamp <phk@FreeBSD.org>
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDQQ0aZ1
u244dqP3sQEBu4ID/jXFFeJgs2MdTDNOZM/FbfDhI4qxAbYUsqS3+Ra16yd8Wd/A
jV+IHJE2NomFWl8UrUjCGinXiwzPgK1OfFJrS9Og1wQLvAl0X84BA8MTP9BQr4w7
6I/RbksgUSrVCIO8MJwlydjSPocWGBeXlVjbZxXzyuJk7H+TG+zuI5BuBcNIiQCV
AwUQMwYr2rNaYutZnzI9AQHiIQP/XxtBWFXaBRgVLEhRNpS07YdU+LsZGlLOZehN
9L4UnJFHQQPNOpMey2gF7Y95aBOw5/1xS5vlQpwmRFCntWsm/gqdzK6rulfr1r5A
y94LO5TAC6ucNu396Y4vo1TyD1STnRC466KlvmtQtAtFGgXlORWLL9URLzcRFd1h
D0yXd9aJAJUDBRAxfo19a1pnjYGyp3kBAQqyA/4v64vP3l1F0Sadn6ias761hkz/
SMdTuLzILmofSCC4o4KWMjiWJHs2Soo41QlZi1+xMHzV32JKiwFlGtPHqL+EHyXy
Q4H3vmf9/1KF+0XCaMtgI0wWUMziPSTJK8xXbRRmMDK/0F4TnVVaUhnmf+h5K7O6
XdmejDTa0X/NWcicmIkAlQMFEDF8lef1FVv7jlQtXQEBcnwD/0ro1PpUtlkLmreD
tsGTkNa7MFLegrYRvDDrHOwPZH152W2jPUncY+eArQJakeHiTDmJNpFagLZglhE0
bqJyca+UwCXX+6upAclWHEBMg2byiWMMqyPVEEnpUoHM1sIkgdNWlfQAmipRBfYh
2LyCgWvR8CbtwPYIFvUmGgB3MR87iQCVAwUQMUseXB9/qQgDWPy9AQGPkwP/WEDy
El2Gkvua9COtMAifot2vTwuvWWpNopIEx0Ivey4aVbRLD90gGCJw8OGDEtqFPcNV
8aIiy3fYVKXGZZjvCKd7zRfhNmQn0eLDcymq2OX3aPrMc2rRlkT4Jx425ukR1gsO
qiQAgw91aWhY8dlw/EKzk8ojm52x4VgXaBACMjaJAJUDBRAxOUOg72G56RHVjtUB
AbL4A/9HOn5Qa0lq9tKI/HkSdc5fGQD/66VdCBAb292RbB7CS/EM07MdbcqRRYIa
0+0gwQ3OdsWPdCVgH5RIhp/WiC+UPkR1cY8N9Mg2kTwJfZZfNqN+BgWlgRMPN27C
OhYNl8Q33Nl9CpBLrZWABF44jPeT0EvvTzP/5ZQ7T75EsYKYiYkAlQMFEDDmryQA
8tkJ67sbQQEBPdsEALCj6v1OBuJLLJTlxmmrkqAZPVzt5QdeO3Eqa2tcPWcU0nqP
vHYMzZcZ7oFg58NZsWrhSQQDIB5e+K65Q/h6dC7W/aDskZd64jxtEznX2kt0/MOr
8OdsDis1K2f9KQftrAx81KmVwW4Tqtzl7NWTDXt44fMOtibCwVq8v2DFkTJy
=JKbP
-----END PGP PUBLIC KEY BLOCK-----&a.rich;
Rich Murphey <rich@FreeBSD.org>
fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1
FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs
wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR
tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W
vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g
Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP
/2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw==
=QoiM
-----END PGP PUBLIC KEY BLOCK-----&a.jdp;
John D. Polstra <jdp@polstra.com>
Fingerprint = 54 3A 90 59 6B A4 9D 61 BF 1D 03 09 35 8D F6 0D
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzMElMEAAAEEALizp6ZW9QifQgWoFmG3cXhzQ1+Gt+a4S1adC/TdHdBvw1M/
I6Ok7TC0dKF8blW3VRgeHo4F3XhGn+n9MqIdboh4HJC5Iiy63m98sVLJSwyGO4oM
dkEGyyCLxqP6h/DU/tzNBdqFzetGtYvU4ftt3RO0a506cr2CHcdm8Q+/vPRJAAUR
tCFKb2huIEQuIFBvbHN0cmEgPGpkcEBwb2xzdHJhLmNvbT6JAJUDBRAzBNBE9RVb
+45ULV0BAWgiA/0WWO3+c3qlptPCHJ3DFm6gG/qNKsY94agL/mHOr0fxMP5l2qKX
O6a1bWkvGoYq0EwoKGFfn0QeHiCl6jVi3CdBX+W7bObMcoi+foqZ6zluOWBC1Jdk
WQ5/DeqQGYXqbYjqO8voCScTAPge3XlMwVpMZTv24u+nYxtLkE0ZcwtY9IkAlQMF
EDMEt/DHZvEPv7z0SQEBXh8D/2egM5ckIRpGz9kcFTDClgdWWtlgwC1iI2p9gEhq
aufy+FUJlZS4GSQLWB0BlrTmDC9HuyQ+KZqKFRbVZLyzkH7WFs4zDmwQryLV5wkN
C4BRRBXZfWy8s4+zT2WQD1aPO+ZsgRauYLkJgTvXTPU2JCN62Nsd8R7bJS5tuHEm
7HGmiQCVAwUQMwSvHB9/qQgDWPy9AQFAhAQAgJ1AlbKITrEoJ0+pLIsov3eQ348m
SVHEBGIkU3Xznjr8NzT9aYtq4TIzt8jplqP3QoV1ka1yYpZf0NjvfZ+ffYp/sIaU
wPbEpgtmHnVWJAebMbNs/Ad1w8GDvxEt9IaCbMJGZnHmfnEqOBIxF7VBDPHHoJxM
V31K/PIoYsHAy5w=
=cHFa
-----END PGP PUBLIC KEY BLOCK-----&a.guido;
Guido van Rooij <guido@gvr.win.tue.nl>
Fingerprint = 16 79 09 F3 C0 E4 28 A7 32 62 FA F6 60 31 C0 ED
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzGeO84AAAEEAKKAY91Na//DXwlUusr9GVESSlVwVP6DyH1wcZXhfN1fyZHq
SwhMCEdHYoojQds+VqD1iiZQvv1RLByBgj622PDAPN4+Z49HjGs7YbZsUNuQqPPU
wRPpP6ty69x1hPKq1sQIB5MS4radpCM+4wbZbhxv7l4rP3RWUbNaYutZnzI9AAUR
tCZHdWlkbyB2YW4gUm9vaWogPGd1aWRvQGd2ci53aW4udHVlLm5sPokAlQMFEDMG
Hcgff6kIA1j8vQEBbYgD/jm9xHuUuY+iXDkOzpCXBYACYEZDV913MjtyBAmaVqYo
Rh5HFimkGXe+rCo78Aau0hc57fFMTsJqnuWEqVt3GRq28hSK1FOZ7ni9/XibHcmN
rt2yugl3hYpClijo4nrDL1NxibbamkGW/vFGcljS0jqXz6NDVbGx5Oo7HBByxByz
iQCVAwUQMhmtVjt/x7zOdmsfAQFuVQQApsVUTigT5YWjQA9Nd5Z0+a/oVtZpyw5Z
OljLJP3vqJdMa6TidhfcatjHbFTve5x1dmjFgMX/MQTd8zf/+Xccy/PX4+lnKNpP
eSf1Y4aK+E8KHmBGd6GzX6CIboyGYLS9e3kGnN06F2AQtaLyJFgQ71wRaGuyKmQG
FwTn7jiKb1aJAJUDBRAyEOLXPt3iN6QQUSEBATwQA/9jqu0Nbk154+Pn+9mJX/YT
fYR2UqK/5FKCqgL5Nt/Deg2re0zMD1f8F9Dj6vuAAxq8hnOkIHKlWolMjkRKkzJi
mSPEWl3AuHJ31k948J8it4f8kq/o44usIA2KKVMlI63Q/rmNdfWCyiYQEVGcRbTm
GTdZIHYCOgV5dOo4ebFqgYkAlQMFEDIE1nMEJn15jgpJ0QEBW6kEAKqN8XSgzTqf
CrxFXT07MlHhfdbKUTNUoboxCGCLNW05vf1A8F5fdE5i14LiwkldWIzPxWD+Sa3L
fNPCfCZTaCiyGcLyTzVfBHA18MBAOOX6JiTpdcm22jLGUWBf/aJK3yz/nfbWntd/
LRHysIdVp29lP5BF+J9/Lzbb/9LxP1taiQCVAwUQMgRXZ44CzbsJWQz9AQFf7gP/
Qa2FS5S6RYKG3rYanWADVe/ikFV2lxuM1azlWbsmljXvKVWGe6cV693nS5lGGAjx
lbd2ADwXjlkNhv45HLWFm9PEveO9Jjr6tMuXVt8N2pxiX+1PLUN9CtphTIU7Yfjn
s6ryZZfwGHSfIxNGi5ua2SoXhg0svaYnxHxXmOtH24iJAJUDBRAyAkpV8qaAEa3W
TBkBARfQBAC+S3kbulEAN3SI7/A+A/dtl9DfZezT9C4SRBGsl2clQFMGIXmMQ/7v
7lLXrKQ7U2zVbgNfU8smw5h2vBIL6f1PyexSmc3mz9JY4er8KeZpcf6H0rSkHl+i
d7TF0GvuTdNPFO8hc9En+GG6QHOqbkB4NRZ6cwtfwUMhk2FHXBnjF4kAlQMFEDH5
FFukUJAsCdPmTQEBe74EAMBsxDnbD9cuI5MfF/QeTNEG4BIVUZtAkDme4Eg7zvsP
d3DeJKCGeNjiCWYrRTCGwaCWzMQk+/+MOmdkI6Oml+AIurJLoHceHS9jP1izdP7f
N2jkdeJSBsixunbQWtUElSgOQQ4iF5kqwBhxtOfEP/L9QsoydRMR1yB6WPD75H7V
iQCVAwUQMZ9YNGtaZ42Bsqd5AQH0PAQAhpVlAc3ZM/KOTywBSh8zWKVlSk3q/zGn
k7hJmFThnlhH1723+WmXE8aAPJi+VXOWJUFQgwELJ6R8jSU2qvk2m1VWyYSqRKvc
VRQMqT2wjss0GE1Ngg7tMrkRHT0il7E2xxIb8vMrIwmdkbTfYqBUhhGnsWPHZHq7
MoA1/b+rK7CJAJUDBRAxnvXh3IDyptUyfLkBAYTDA/4mEKlIP/EUX2Zmxgrd/JQB
hqcQlkTrBAaDOnOqe/4oewMKR7yaMpztYhJs97i03Vu3fgoLhDspE55ooEeHj0r4
cOdiWfYDsjSFUYSPNVhW4OSruMA3c29ynMqNHD7hpr3rcCPUi7J2RncocOcCjjK2
BQb/9IAUNeK4C9gPxMEZLokAlQMFEDGeO86zWmLrWZ8yPQEBEEID/2fPEUrSX3Yk
j5TJPFZ9MNX0lEo7AHYjnJgEbNI4pYm6C3PnMlsYfCSQDHuXmRQHAOWSdwOLvCkN
F8eDaF3M6u0urgeVJ+KVUnTz2+LZoZs12XSZKCte0HxjbvPpWMTTrYyimGezH79C
mgDVjsHaYOx3EXF0nnDmtXurGioEmW1J
=mSvM
-----END PGP PUBLIC KEY BLOCK-----&a.peter;
Peter Wemm <peter@FreeBSD.org>
aka <peter@spinner.dialix.com>
aka <peter@haywire.dialix.com>
aka <peter@perth.dialix.oz.au>
Key fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/
W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2
kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT
tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMwWT
cXW7bjh2o/exAQEFkQP+LIx5zKlYp1uR24xGApMFNrNtjh+iDIWnxxb2M2Kb6x4G
9z6OmbUCoDTGrX9SSL2Usm2RD0BZfyv9D9QRWC2TSOPkPRqQgIycc11vgbLolJJN
eixqsxlFeKLGEx9eRQCCbo3dQIUjc2yaOe484QamhsK1nL5xpoNWI1P9zIOpDiGJ
AJUDBRAxsRPqSoY3Ydic4xkBAbWLA/9q1Fdnnk4unpGQsG31Qbtr4AzaQD5m/JHI
4gRmSmbj6luJMgNG3fpO06Gd/Z7uxyCJB8pTst2a8C/ljOYZxWT+5uSzkQXeMi5c
YcI1sZbUpkHtmqPW623hr1PB3ZLA1TIcTbQW+NzJsxQ1Pc6XG9fGkT9WXQW3Xhet
AP+juVTAhLQlUGV0ZXIgV2VtbSA8cGV0ZXJAcGVydGguZGlhbGl4Lm96LmF1PokA
lQMFEDGxFCFKhjdh2JzjGQEB6XkD/2HOwfuFrnQUtdwFPUkgtEqNeSr64jQ3Maz8
xgEtbaw/ym1PbhbCk311UWQq4+izZE2xktHTFClJfaMnxVIfboPyuiSF99KHiWnf
/Gspet0S7m/+RXIwZi1qSqvAanxMiA7kKgFSCmchzas8TQcyyXHtn/gl9v0khJkb
/fv3R20btB5QZXRlciBXZW1tIDxwZXRlckBGcmVlQlNELm9yZz6JAJUDBRAxsRJd
SoY3Ydic4xkBAZJUA/4i/NWHz5LIH/R4IF/3V3LleFyMFr5EPFY0/4mcv2v+ju9g
brOEM/xd4LlPrx1XqPeZ74JQ6K9mHR64RhKR7ZJJ9A+12yr5dVqihe911KyLKab9
4qZUHYi36WQu2VtLGnw/t8Jg44fQSzbBF5q9iTzcfNOYhRkSD3BdDrC3llywO7Ql
UGV0ZXIgV2VtbSA8cGV0ZXJAc3Bpbm5lci5kaWFsaXguY29tPokAlQMFEDGxEi1K
hjdh2JzjGQEBdA4EAKmNFlj8RF9HQsoI3UabnvYqAWN5wCwEB4u+Zf8zq6OHic23
TzoK1SPlmSdBE1dXXQGS6aiDkLT+xOdeewNs7nfUIcH/DBjSuklAOJzKliXPQW7E
kuKNwy4eq5bl+j3HB27i+WBXhn6OaNNQY674LGaR41EGq44Wo5ATcIicig/z
=gv+h
-----END PGP PUBLIC KEY BLOCK-----&a.joerg;
Type Bits/KeyID Date User ID
pub 1024/76A3F7B1 1996/04/27 Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Key fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
Joerg Wunsch <joerg_wunsch@interface-business.de>
Joerg Wunsch <j@uriah.heep.sax.de>
Joerg Wunsch <j@interface-business.de>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz
q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe
ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR
tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J
AJUDBRA0FFkBs1pi61mfMj0BAfDCA/oCfkjrhvRwRCpSL8klJ1YDoUJdmw+v4nJc
pw3OpYXbwKOPLClsE7K3KCQscHel7auf91nrekAwbrXv9Clp0TegYeAQNjw5vZ9f
L6UZ5l3fH8E2GGA7+kqgNWs1KxAnG5GdUvJ9viyrWm8dqWRGo+loDWlZ12L2OgAD
fp7jVZTI1okAlQMFEDQPrLoff6kIA1j8vQEB2XQEAK/+SsQPCT/X4RB/PBbxUr28
GpGJMn3AafAaA3plYw3nb4ONbqEw9tJtofAn4UeGraiWw8nHYR2DAzoAjR6OzuX3
TtUV+57BIzrTPHcNkb6h8fPuHU+dFzR+LNoPaGJsFeov6w+Ug6qS9wa5FGDAgaRo
LHSyBxcRVoCbOEaS5S5EiQCVAwUQM5BktWVgqaw0+fnVAQGKPwP+OiWho3Zm2GKp
lEjiZ5zx3y8upzb+r1Qutb08jr2Ewja04hLg0fCrt6Ad3DoVqxe4POghIpmHM4O4
tcW92THQil70CLzfCxtfUc6eDzoP3krD1/Gwpm2hGrmYA9b/ez9+r2vKBbnUhPmC
glx5pf1IzHU9R2XyQz9Xu7FI2baOSZqJAJUDBRAyCIWZdbtuOHaj97EBAVMzA/41
VIph36l+yO9WGKkEB+NYbYOz2W/kyi74kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoL
oAKxE25AoCgl5towqr/sCcu0A0MMvJddUvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zz
xzLIvtcio6kaHd76XxyJpltCASupdD53nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxq
b2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDIIhfR1u244
dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX
+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvckfxvrTgzSzvtYyv1072X3GkVY+SlUMBMA
rdl1qNW23oT7Q558ajnsaL065XJ5m7HacgTTikiofYG8i1s7TrsEeq6PtCJKb2Vy
ZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5zYXguZGU+iQCVAwUQMaS91D4gHQUlG9CZ
AQGYOwQAhPpiobK3d/fz+jWrbQgjkoO+j39glYGXb22+6iuEprFRs/ufKYtjljNT
NK3B4DWSkyIPawcuO4Lotijp6jke2bsjFSSashGWcsJlpnwsv7EeFItT3oWTTTQQ
ItPbtNyLW6M6xB+jLGtaAvJqfOlzgO9BLfHuA2LY+WvbVW447SWJAJUDBRAxqWRs
dbtuOHaj97EBAXDBA/49rzZB5akkTSbt/gNd38OJgC+H8N5da25vV9dD3KoAvXfW
fw7OxIsxvQ/Ab+rJmukrrWxPdsC+1WU1+1rGa4PvJp/VJRDes2awGrn+iO7/cQoS
IVziC27JpcbvjLvLVcBIiy1yT/RvJ+87a3jPRHt3VFGcpFh4KykxxSNiyGygl4kA
lQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJZe5lFkPr2B/Cr7BKMVBot1/JSu05NsHg
JZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDFe/GF0HZD/ZD1FJt8yQjzF2w340B+F2GG
EOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gpkFZrFgg5eON7ikqmusDnOlYStM/CBfgp
SbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokA
lQMFEDHioSdlYKmsNPn51QEByz8D/10uMrwP7MdaXnptd1XNFhpaAPYTVAOcaKlY
OGI/LLR9PiU3FbqXO+7INhaxFjBxa0Tw/p4au5Lq1+Mx81edHniJZNS8tz3I3goi
jIC3+jn2gnVAWnK5UZUTUVUn/JLVk/oSaIJNIMMDaw4J9xPVVkb+Fh1A+XqtPsVa
YESrNp0+iQCVAwUQMwXkzcdm8Q+/vPRJAQEA4QQAgNNX1HFgXrMetDb+w6yEGQDk
JCDAY9b6mA2HNeKLQAhsoZl4HwA1+iuQaCgo3lyFC+1Sf097OUTs74z5X1vCedqV
oFw9CxI3xuctt3pJCbbN68flOlnq0WdYouWWGlFwLlh5PEy//VtwX9lqgsizlhzi
t+fX6BT4BgKi5baDhrWJAJUDBRAyCKveD9eCJxX4hUkBAebMA/9mRPy6K6i7TX2R
jUKSl2p5oYrXPk12Zsw4ijuktslxzQhOCyMSCGK2UEC4UM9MXp1H1JZQxN/DcfnM
7VaUt+Ve0wZ6DC9gBSHJ1hKVxHe5XTj26mIr4rcXNy2XEDMK9QsnBxIAZnBVTjSO
LdhqqSMp3ULLOpBlRL2RYrqi27IXr4kAlQMFEDGpbnd1u244dqP3sQEBJnQD/RVS
Azgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyudZkNkI5zGGDwVneH/cSkKT4OR
ooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8orsQGGWIn5FhqYXsKkjEGxIOBOf
vvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU
=97h7
-----END PGP PUBLIC KEY BLOCK-----
+
+
+ Developers
+
+
+ &a.wosch;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/2B7181AD 1997/08/09 Wolfram Schneider <wosch@FreeBSD.org>
+Fingerprint = CA 16 91 D9 75 33 F1 07 1B F0 B4 9F 3E 95 B6 09
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzPs+aEAAAEEAJqqMm2I9CxWMuHDvuVO/uh0QT0az5ByOktwYLxGXQmqPG1G
+Q3hVuHWYs5Vfm/ARU9CRcVHFyqGQ3LepoRhDHk+JcASHan7ptdFsz7xk1iNNEoe0
+vE2rns38HIbiyQ/2OZd4XsyhFOFtExNoBuyDyNoe3HbHVBQT7TmN/mkrcYGtAAUR
+tCVXb2xmcmFtIFNjaG5laWRlciA8d29zY2hARnJlZUJTRC5vcmc+iQCVAwUQNmrS
+AzmN/mkrcYGtAQFQjAP8CthNueur8XDAZqC5q6NQcDs0PqqQ+raTUfQTv6Km6ykf
+UzdpDlBoRC+CCyHfBfC5zo9N6mB7iV7qS1PljrdIh6VAwHxJN9iopB/x6+nsBvmy
+0YSNt7eyfFrIVegCJvd4ALz5JBV8ZstznOwo8RAhDD0gX58F8nDhgWjy62JekGK0
+IldvbGZyYW0gU2NobmVpZGVyIDx3b3NjaEBhcGZlbC5kZT6JARUDBRA2Z9ZcCMks
+sk6wLt0BAQBICACcTiDZ/AyYWRDLXsBOK+WMRoNk3+bQZ1cdy11nwJo+taT/389M
+0r5TrEJ7CogpXC2rFUExTVWldSFZd8A1YIHtrTsP7YauUH0nA7k0wUnqDRYj8YJR
+eMLFvc1OQ2y+mkvxF2BzzBzh/bcYbgJdWCB1MPahSNQfkGXtp+A5PjEs8Cp4+FLu
+EUFScyxsD3g5/E+0d7mirJpe3pxcf9KCmFGHM89mrTKODQR/7N8dVqa9npeXZotm
+ZK8Jz+tvRKFgNiLf2XL048+IE8ZtJXDYaDzTirHdcAqJMWQuxthCdG3ta4I+w5WM
+WR8JtBLfVNpyU7LN6dl0IB7O5sYhyskApmMwiQCVAwUQM+z5oTmN/mkrcYGtAQGU
+gAP/cJGro/SbV+L19s/Gem26KmegUH+bfIXoh2EzyRJ7heVdybu1LrSDFApmAE7d
+sMDlAA1wd2XjVWD3nIEBl6k+J7qJB4ACjKVGs414jLpdKGPHdLRYqYDj4LyQFMv6
+/BpSoX1gnWp6xlC2xeWRan9ns3XZGS55UBVDvBE/B+fPoTe0JFdvbGZyYW0gU2No
+bmVpZGVyIDxzY2huZWlkZXJAemliLmRlPokAlQMFEDZq0dI5jf5pK3GBrQEB38QD
+/3NYyRPIejtXXq/okdDRyhWmA8cv0KG6gEupKCQKa7ep/OZTw/KxrN3ZOS8zlPod
+tEn8mol+4SvY5AgSMdjQ0jTd1JdFcMKFnbJJrJ3b9IpwCqbkXy25rTUcQn9ICP47
+rFKC4qR/Ucrg5YVVhQ3pVJX6XuO2XvuG7euHAQNXV3e2
+=EpJQ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+ &a.brian;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/666A7421 1997/04/30 Brian Somers <brian@Awfulhak.org>
+ Key fingerprint = 2D 91 BD C2 94 2C 46 8F 8F 09 C4 FC AD 12 3B 21
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzNmogUAAAEEALdsjVsV2dzO8UU4EEo7z3nYuvB2Q6YJ8sBUYjB8/vfR5oZ9
+7aEQjgY5//pXvS30rHUB9ghk4kIFSljzeMudE0K2zH5n2sxpLbBKWZRDLS7xnrDC
+I3j9CNKwQBzMPs0fUT46gp96nf1X8wPiJXkDUEia/c0bRbXlLw7tvOdmanQhAAUR
+tCFCcmlhbiBTb21lcnMgPGJyaWFuQGF3ZnVsaGFrLm9yZz6JAJUDBRAzbedc77Ox
+BWZTbW0BAVtFA/42QelA3RBXYUtIcYGob+QsWkA1kGyBKQGPSS9coHdUVjClBRl3
+UZFmZhxAODb7cBRXmpvx2ZuMrhn/MpXTMqPOJaE3FYm+5SoeArphsRU+T8XofxfL
+vRHkM3JURUjIVZdAQNvxxBso8NJG5KayP0Q96Vw+3sEwFK49jt14RCJy4IkAlQMF
+EDNzvb1sq+iWcxFJBQEBfZwD/R3KNFf9ype9Dea8j1YIeNZ1E3e03en1I8fMj6Em
+S1/L1WfFzMnfFCxZs7JgPtkBuB3CqP8f+LOdDt6PHPqNakmI9E6fiuGfJZ3jFZYA
+TXa0XKuIoxIJNKhqkpbF8ixJZFTxFwAAwVYM3+sqr4qQ8FzVc5entxjyxPFNkwJw
+RWV+iQCVAwUQM2aiBQ7tvOdmanQhAQE7LgQAiN6Hz+zd8bh0nO6VizbJxWFRHPbr
+QWnJXGoMYyy88DyszAXC4zRshlyGUDQdHeP/1DFCXDEu78GfDCLaJ1bm25yVR7kL
+xDZaEUQEbWqxfiwuzizAjkaxrW7dBbWILwWqrYF5TXClw+oUU/oIUW4t6t+GpAO1
+8PLYhSMXVYErrAA=
+=EdyZ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
diff --git a/en_US.ISO8859-1/books/handbook/ports/chapter.sgml b/en_US.ISO8859-1/books/handbook/ports/chapter.sgml
index 092d021ad9..59c780838e 100644
--- a/en_US.ISO8859-1/books/handbook/ports/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/ports/chapter.sgml
@@ -1,4523 +1,4673 @@
Installing Applications: The Ports collectionContributed by &a.jraynard;.The FreeBSD Ports collection allows you to compile and install a
very wide range of applications with a minimum of effort.For all the hype about open standards, getting a program to work
on different versions of Unix in the real world can be a tedious and
tricky business, as anyone who has tried it will know. You may be
lucky enough to find that the program you want will compile cleanly on
your system, install itself in all the right places and run flawlessly
“out of the box”, but this is unfortunately rather rare. With most
programs, you will find yourself doing a fair bit of head-scratching,
and there are quite a few programs that will result in premature
greying, or even chronic alopecia...Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but
they have an unfortunate tendency to triumphantly announce that your
system is something you have never heard of and then ask you lots of
questions that sound like a final exam in system-level Unix
programming (Does your system's gethitlist function return a const
pointer to a fromboz or a pointer to a const fromboz? Do you have
Foonix style unacceptable exception handling? And if not, why
not?).Fortunately, with the Ports collection, all the hard work
involved has already been done, and you can just type make install
and get a working program.Why Have a Ports Collection?The base FreeBSD system comes with a very wide range of tools
and system utilities, but a lot of popular programs are not in the
base system, for good reasons:-Programs that some people cannot live without and other
people cannot stand, such as a certain Lisp-based editor.Programs which are too specialised to put in the base
system (CAD, databases).Programs which fall into the “I must have a look at that
when I get a spare minute” category, rather than
system-critical ones (some languages, perhaps).Programs that are far too much fun to be supplied with a
serious operating system like FreeBSD ;-)However many programs you put in the base system, people
will always want more, and a line has to be drawn somewhere
(otherwise FreeBSD distributions would become absolutely
enormous).Obviously it would be unreasonable to expect everyone to port
their favourite programs by hand (not to mention a tremendous amount
of duplicated work), so the FreeBSD Project came up with an
ingenious way of using standard tools that would automate the
process.Incidentally, this is an excellent illustration of how “the
Unix way” works in practice by combining a set of simple but very
flexible tools into something very powerful.How Does the Ports Collection Work?Programs are typically distributed on the Internet as a
tarball consisting of a
Makefile and the source code for the program and usually some
instructions (which are unfortunately not always as instructive as
they could be), with perhaps a configuration script.The standard scenario is that you FTP down the tarball, extract
it somewhere, glance through the instructions, make any changes
that seem necessary, run the configure script to set things up and
use the standard make program to compile and install the program
from the source.FreeBSD ports still use the tarball mechanism, but use a
skeleton to hold the
"knowledge" of how to get the program working on FreeBSD,
rather than expecting the user to be able to work it out. They also
supply their own customised
Makefile, so that almost
every port can be built in the same way.If you look at a port skeleton (either on your FreeBSD
system or the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about Getting a port).“How on earth can this do anything?” I hear you cry. “There
is no source code there!”Fear not, gentle reader, all will become clear (hopefully).
Let's see what happens if we try and install a port. I have chosen
ElectricFence, a useful tool for developers, as the skeleton is
more straightforward than most.If you are trying this at home, you
will need to be root.&prompt.root; cd /usr/ports/devel/ElectricFence
&prompt.root; make install
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
===> Extracting for ElectricFence-2.0.5
===> Patching for ElectricFence-2.0.5
===> Applying FreeBSD patches for ElectricFence-2.0.5
===> Configuring for ElectricFence-2.0.5
===> Building for ElectricFence-2.0.5
[lots of compiler output...]
===> Installing for ElectricFence-2.0.5
===> Warning: your umask is "0002". If this is not desired, set it to
an appropriate value and install this port again by ``make reinstall''.
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
===> Compressing manual pages for ElectricFence-2.0.5
===> Registering installation for ElectricFence-2.0.5To avoid confusing the issue, I have completely removed the
build output.If you tried this yourself, you may well have got something like
this at the start:-&prompt.root; make install
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.The make program has noticed that you did not have a local
copy of the source code and tried to FTP it down so it could get the
job done. I already had the source handy in my example, so it did
not need to fetch it.Let's go through this and see what the make program was
doing.Locate the source code tarball. If it is not available locally, try to
grab it from an FTP site.Run a checksum
test on the tarball to make sure it has not been tampered
with, accidentally truncated, downloaded in ASCII mode, struck
by neutrinos while in transit, etc.Extract the tarball into a temporary work directory.Apply any patches
needed to get the source to compile and run under FreeBSD.Run any configuration script required by the build
process and correctly answer any questions it asks.(Finally!) Compile the code.Install the program executable and other supporting
files, man pages, etc. under the
/usr/local hierarchy, where they will not
get mixed up with system programs. This also makes sure that
all the ports you install will go in the same place, instead
of being flung all over your system.Register the installation in a database. This means that,
if you do not like the program, you can cleanly remove all traces of it from
your system.Scroll up to the make output and see if you can match these
steps to it. And if you were not impressed before, you should be by
now!Getting a FreeBSD PortThere are two ways of getting hold of the FreeBSD port for a
program. One requires a FreeBSD
CDROM, the other involves using an Internet Connection.Compiling ports from CDROMAssuming that your FreeBSD CDROM is in the drive and mounted on
/cdrom (and the mount point
must be /cdrom), you should
then be able to build ports just as you normally do and the port
collection's built in search path should find the tarballs in
/cdrom/ports/distfiles/ (if they exist there)
rather than downloading them over the net.
-
+
+ Another way of doing this, if you want to just use the port
+ skeletons on the CDROM, is to set these variables in
+ /etc/make.conf:
+
+
+PORTSDIR= /cdrom/ports
+DISTDIR= /tmp/distfiles
+WRKDIRPREFIX= /tmp
+
+ Substitute /tmp for any place you have enough
+ free space. Then, just cd to the appropriate
+ subdirectory under /cdrom/ports and type
+ make install as
+ usual. WRKDIRPREFIX will cause the port to be
+ build under /tmp/cdrom/ports; for instance,
+ games/oneko will be built under
+ /tmp/cdrom/ports/games/oneko.
+
There are some ports for which we cannot provide the
original source in the CDROM due to licensing limitations. In
that case, you will need to look at the section on Compiling ports using an Internet connection.Compiling ports from the InternetIf you do not have a CDROM, or you want to make sure you get
the very latest version of the port you want, you will need to
download the
skeleton for the port. Now
this might sound like rather a fiddly job full of pitfalls, but
it is actually very easy.First, if you are running a release version of FreeBSD, make
sure you get the appropriate “upgradekiet” for your
replease from the ports
web page. These packages include files that have been
updated since the release that you may need to compile new
ports.The key to the skeletons is that the FreeBSD FTP server can create
on-the-fly
tarballs for you. Here is
how it works, with the gnats program in the databases directory as
an example (the bits in square brackets are comments. Do not type
them in if you are trying this yourself!):-&prompt.root; cd /usr/ports
&prompt.root; mkdir databases
&prompt.root; cd databases
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports/databases
+>cd /pub/FreeBSD/ports/ports/databases>get gnats.tar
[tars up the gnats skeleton for us]
>quit
&prompt.root; tar xf gnats.tar
[extract the gnats skeleton]
&prompt.root; cd gnats
&prompt.root; make install
[build and install gnats]What happened here? We connected to the FTP server in the
usual way and went to its databases sub-directory. When we gave it
the command get gnats.tar, the FTP server tarred up the gnats directory for us.We then extracted the gnats skeleton and went into the gnats
directory to build the port. As we explained earlier, the make process noticed we did not have a
copy of the source locally, so it fetched one before extracting,
patching and building it.Let's try something more ambitious now. Instead of getting a
single port skeleton, let's get a whole sub-directory, for example
all the database skeletons in the ports collection. It looks
almost the same:-&prompt.root; cd /usr/ports
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports
+>cd /pub/FreeBSD/ports/ports>get databases.tar
[tars up the databases directory for us]
>quit
&prompt.root; tar xf databases.tar
[extract all the database skeletons]
&prompt.root; cd databases
&prompt.root; make install
[build and install all the database ports]With half a dozen straightforward commands, we have now got a
set of database programs on our FreeBSD machine! All we did that
was different from getting a single port skeleton and building it
was that we got a whole directory at once, and compiled everything
in it at once. Pretty impressive, no?If you expect to be installing many ports, it is probably
worth downloading all the ports directories.SkeletonsA team of compulsive hackers who have forgotten to eat in a
frantic attempt to make a deadline? Something unpleasant lurking in
the FreeBSD attic? No, a skeleton here is a minimal framework that
supplies everything needed to make the ports magic work.MakefileThe most important component of a skeleton is the Makefile.
This contains various statements that specify how the port should
be compiled and installed. Here is the Makefile for
ElectricFence:-
# New ports collection makefile for: Electric Fence
# Version required: 2.0.5
# Date created: 13 November 1997
# Whom: jraynard
#
# $Id$
#
DISTNAME= ElectricFence-2.0.5
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SUNSITE}
MASTER_SITE_SUBDIR= devel/lang/c
MAINTAINER= jraynard@freebsd.org
MAN3= libefence.3
do-install:
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
.include <bsd.port.mk>The lines beginning with a "#" sign are comments for
the benefit of human readers (as in most Unix script
files).DISTNAME specifies the name of the tarball, but without the
extension.CATEGORIES states what kind of program this is. In
this case, a utility for developers. See the categories section of this
handbook for a complete list.MASTER_SITES is the URL(s) of the master FTP site,
which is used to retrieve the tarball if it is not available on the local system.
This is a site which is regarded as reputable, and is normally the
one from which the program is officially distributed (in so far
as any software is "officially" distributed on the
Internet).MAINTAINER is the email address of the person who is
responsible for updating the skeleton if, for example a new
version of the program comes out.Skipping over the next few lines for a minute, the line
.include <bsd.port.mk> says
that the other statements and commands needed for this port are
in a standard file called bsd.port.mk. As
these are the same for all ports, there is no point in duplicating
them all over the place, so they are kept in a single standard
file.This is probably not the place to go into a detailed
examination of how Makefiles work; suffice it to say that the line
starting with MAN3 ensures that the ElectricFence man page is
compressed after installation, to help conserve your precious disk
space. The original port did not provide an install target,
so the three lines from do-install ensure that the files
produced by this port are placed in the correct
destination.The files directoryThe file containing the checksum for the port is called
md5, after the MD5 algorithm used for ports
checksums. It lives in a directory with the slightly confusing
name of files.This directory can also contain other miscellaneous files that
are required by the port and do not belong anywhere else.The patches directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The pkg directoryThis program contains three quite useful files:-COMMENT — a one-line description of
the program.DESCR — a more detailed description.PLIST — a list of all the files
that will be created when the program is installed.What to do when a port does not work.Oh. You can do one of four (4) things :Fix it yourself. Technical details on how ports work can
be found in
Porting applications.Gripe. This is done by e-mail only! Send such e-mail to
the &a.ports; and please include the name/version of the port,
where you got both the port source & distfile(s) from, and
what the text of the error was.Forget it. This is the easiest for most — very few of the
programs in ports can be classified as essential!Grab the pre-compiled package from a ftp server. The
“master” package collection is on FreeBSD's FTP server in
the packages
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/">packages
directory, though check your local mirror first,
please! These are more likely to work (on the whole) than
trying to compile from source and a lot faster besides! Use
the pkg_add1 program to install a
package file on your system.Some Questions and AnswersQ. I thought this was going to be a discussion about
modems??!A. Ah. You must be thinking of the serial ports on the
back of your computer. We are using “port” here to mean the
result of “porting” a program from one version of Unix to
another. (It is an unfortunate bad habit of computer people to
use the same word to refer to several completely different
things).Q. I thought you were supposed to use packages to install
extra programs?A. Yes, that is usually the quickest and easiest way of
doing it.Q. So why bother with ports then?A. Several reasons:-The licensing conditions on some software
distributions require that they be distributed as source
code, not binaries.Some people do not trust binary distributions. At
least with source code you can (in theory) read through
it and look for potential problems yourself.If you have some local patches, you will need the
source to add them yourself.You might have opinions on how a program should be
compiled that differ from the person who did the package
— some people have strong views on what optimisation
setting should be used, whether to build debug versions
and then strip them or not, etc. etc.Some people like having code around, so they can
read it if they get bored, hack around with it, borrow
from it (licence terms permitting, of course!) and so
on.If you ain't got the source, it ain't software!
;-) Q. What is a patch?A. A patch is a small (usually) file that specifies how to
go from one version of a file to another. It contains text
that says, in effect, things like “delete line 23”, “add
these two lines after line 468” or “change line 197 to
this”. Also known as a “diff”, since it is generated by a
program of that name. Q. What is all this about
tarballs?A. It is a file ending in .tar or
.tar.gz (with variations like
.tar.Z, or even .tgz
if you are trying to squeeze the names into a DOS
filesystem).Basically, it is a directory tree that has been archived
into a single file (.tar) and optionally
compressed (.gz). This technique was
originally used for Tape
ARchives (hence the name tar), but it is
a widely used way of distributing program source code around
the Internet.You can see what files are in them, or even extract them
yourself, by using the standard Unix tar program, which comes
with the base FreeBSD system, like this:-&prompt.user; tar tvzf foobar.tar.gz
&prompt.user; tar xzvf foobar.tar.gz
&prompt.user; tar tvf foobar.tar
&prompt.user; tar xvf foobar.tar Q. And a checksum?A. It is a number generated by adding up all the data in
the file you want to check. If any of the characters change,
the checksum will no longer be equal to the total, so a simple
comparison will allow you to spot the difference. (In
practice, it is done in a more complicated way to spot
problems like position-swapping, which will not show up with a
simplistic addition).Q. I did what you said for compiling ports from a CDROM and it worked great
until I tried to install the kermit port:-&prompt.root; make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.Why can it not be found? Have I got a dud CDROM?A. The licensing terms for kermit do not allow us to put
the tarball for it on the CDROM, so you will have to fetch it
by hand — sorry! The reason why you got all those error
messages was because you were not connected to the Internet at
the time. Once you have downloaded it from any of the sites
above, you can re-start the process (try and choose the
nearest site to you, though, to save your time and the
Internet's bandwidth).Q. I did that, but when I tried to put it into
/usr/ports/distfiles I got some error
about not having permission.A. The ports mechanism looks for the tarball in
/usr/ports/distfiles, but you will not be
able to copy anything there because it is sym-linked to the
CDROM, which is read-only. You can tell it to look somewhere
else by doing&prompt.root; make DISTDIR=/where/you/put/it installQ. Does the ports scheme only work if you have everything
in /usr/ports? My system administrator
says I must put everything under
/u/people/guests/wurzburger, but it does
not seem to work.A. You can use the PORTSDIR and PREFIX variables to tell
the ports mechanism to use different directories. For
instance,&prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports installwill compile the port in
/u/people/guests/wurzburger/ports and
install everything under /usr/local.&prompt.root; make PREFIX=/u/people/guests/wurzburger/local installwill compile it in /usr/ports and
install it in
/u/people/guests/wurzburger/local.And of course&prompt.root; make PORTSDIR=.../ports PREFIX=.../local installwill combine the two (it is too long to fit on the page if
I write it in full, but I am sure you get the idea).If you do not fancy typing all that in every time you
install a port (and to be honest, who would?), it is a good
idea to put these variables into your environment.Q. I do not have a FreeBSD CDROM, but I would like to have
all the tarballs handy on my system so I do not have to wait
for a download every time I install a port. Is there an easy
way to get them all at once?A. To get every single tarball for the ports collection,
do&prompt.root; cd /usr/ports
&prompt.root; make fetchFor all the tarballs for a single ports directory,
do&prompt.root; cd /usr/ports/directory
&prompt.root; make fetchand for just one port — well, I think you have guessed
already.Q. I know it is probably faster to fetch the tarballs from
one of the FreeBSD mirror sites close by. Is there any way to
tell the port to fetch them from servers other than ones
listed in the MASTER_SITES?A. Yes. If you know, for example, ftp.FreeBSD.ORG is much
closer than sites listed in MASTER_SITES, do as following
example.&prompt.root; cd /usr/ports/directory
-&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
+&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetchQ. I want to know what files make is going to need before
it tries to pull them down.A. make fetch-list will display a list of the files
needed for a port.Q. Is there any way to stop the port from compiling? I
want to do some hacking on the source before I install it, but
it is a bit tiresome having to watch it and hit control-C
every time.A. Doing make extract will stop it after it has fetched
and extracted the source code.Q. I am trying to make my own port and I want to be able
to stop it compiling until I have had a chance to see if my
patches worked properly. Is there something like make
extract, but for patches?A. Yep, make patch is what you want. You will probably
find the PATCH_DEBUG option useful as well. And by the way,
thank you for your efforts!Q. I have heard that some compiler options can cause bugs.
Is this true? How can I make sure that I compile ports with
the right settings?A. Yes, with version 2.6.3 of gcc (the version shipped
with FreeBSD 2.1.0 and 2.1.5), the option could result in
buggy code unless you used the option as
well. (Most of the ports don't use ). You
should be able to specify the compiler
options used by something like&prompt.root; make CFLAGS='-O2 -fno-strength-reduce' installor by editing /etc/make.conf, but
unfortunately not all ports respect this. The surest way is to
do make configure, then go into the source directory and
inspect the Makefiles by hand, but this can get tedious if the
source has lots of sub-directories, each with their own
Makefiles.Q. There are so many ports it is hard to find the one I
want. Is there a list anywhere of what ports are available?A. Look in the INDEX file in
/usr/ports. If you would like to search the
ports collection for a keyword, you can do that too. For example,
you can find ports relevant to the LISP programming language
using:&prompt.user; cd /usr/ports
&prompt.user; make search key=lispQ. I went to install the foo port but the system
suddenly stopped compiling it and starting compiling the
bar
port. What's going on?A. The foo port needs something that is supplied with
bar — for instance, if foo uses graphics, bar might have
a library with useful graphics processing routines. Or bar
might be a tool that is needed to compile the foo
port. Q. I installed the grizzle
program from the ports and frankly it is a complete waste of
disk space. I want to delete it but I do not know where it put
all the files. Any clues?A. No problem, just do&prompt.root; pkg_delete grizzle-6.5
Q. Hang on a minute, you have to know the version number to
use that command. You do not seriously expect me to remember
that, do you??A. Not at all, you can find it out by doing&prompt.root; pkg_info -a | grep grizzle
Information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.Q. Talking of disk space, the ports directory seems to be
taking up an awful lot of room. Is it safe to go in there and
delete things?A. Yes, if you have installed the program and are fairly
certain you will not need the source again, there is no point
in keeping it hanging around. The best way to do this
is&prompt.root; cd /usr/ports
&prompt.root; make cleanwhich will go through all the ports subdirectories and
delete everything except the skeletons for each port.Q. I tried that and it still left all those tarballs or
whatever you called them in the distfiles
directory. Can I delete those as well?A. Yes, if you are sure you have finished with them, those
can go as well.Q. I like having lots and lots of programs to play with.
Is there any way of installing all the ports in one go?A. Just do&prompt.root; cd /usr/ports
&prompt.root; make installQ. OK, I tried that, but I thought it would take a very
long time so I went to bed and left it to get on with it. When
I looked at the computer this morning, it had only done three
and a half ports. Did something go wrong?A. No, the problem is that some of the ports need to ask
you questions that we cannot answer for you (eg “Do you want
to print on A4 or US letter sized paper?”) and they need to
have someone on hand to answer them.Q. I really do not want to spend all day staring at the
monitor. Any better ideas?A. OK, do this before you go to bed/work/the local
park:-&prompt.root cd /usr/ports
&prompt.root; make -DBATCH installThis will install every port that does
not require user input. Then, when you
come back, do&prompt.root; cd /usr/ports
&prompt.root; make -DIS_INTERACTIVE installto finish the job.Q. At work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do
what we need. Is there any way of making our own packages, so
we can distribute it more easily around our sites?A. No problem, assuming you know how to make patches for
your changes:-&prompt.root; cd /usr/ports/somewhere/frobble
&prompt.root; make extract
&prompt.root; cd work/frobble-2.8
[Apply your patches]
&prompt.root; cd ../..
&prompt.root; make packageQ. This ports stuff is really clever. I am desperate to
find out how you did it. What is the secret?A. Nothing secret about it at all, just look at the
bsd.ports.mk and
bsd.ports.subdir.mk files in your makefiles
directory.Readers with an aversion to intricate shell-scripts are
advised not to follow this link...)Making a port yourselfContributed by &a.jkh;, &a.gpalmer;, &a.asami;
&a.obrien; and &a.hoek;. 28 August 1996.So, now you are interested in making your own port?
Great!What follows are some guidelines for creating a new port for
FreeBSD. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Only a fraction of the overridable variables
(VAR) are mentioned
in this document. Most (if not all) are documented at the start of
bsd.port.mk. This file users a non-standard
tab setting. Emacs and
Vim should recognise the setting on
loading the file. vi or ex
can be set to use the correct value by typing :set
tabstop=4 once the file has been loaded.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into DISTDIR, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the MakefileThe minimal Makefile would
look something like this:
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# $Id$
#
DISTNAME= oneko-1.1b
CATEGORIES= games
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG
MAN1= oneko.1
MANCOMPRESSED= yes
USE_IMAKE= yes
.include <bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the sample Makefile
section.Writing the description filesThere are three description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.COMMENTThis is the one-line description of the port.
Please do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the screen.DESCRThis is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual or an
in-depth description on how to use or compile the port!
Please be careful if you are copying from the
README or manpage; too often
they are not a concise description of the port or are in an
awkward format (e.g., manpages have justified spacing). If the
ported software has an official WWW homepage, you should list
it here.It is recommended that you sign the name at the end of
this file, as in:
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
http://www.oneko.org/
- Satoshi
asami@cs.berkeley.eduPLISTThis file lists all the files installed by the port. It
is also called the “packing list” because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). If you are using the
MANn variables (as
you should be), do not list any manpages here.Here is a small example:
bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/onekoRefer to the pkg_create1 man page
for details on the packing list.You should list all the files, but not the name
directories, in the list. Also, if the port creates
directories for itself during installtion, make sure to add
@dirrm lines as necessary to remove them
when the port is deleted.It is recommended that you keep all the filenames in
this file sorted alphabetically. It will make verifying the
changes when you upgrade the port much easier.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. These are
the important points you need to verify.PLIST does not contain anything not
installed by your portPLIST contains everything that is
installed by your portYour port can be installed multiple times using the
reinstall targetYour port cleans
up after itself upon deinstallRecommended test orderingmake installmake packagemake deinstallpkg_add `make package-name`make deinstallmake reinstallmake packageMake sure that there aren't any warnings issued in any of
the package and
deinstall stages, After step 3, check
to see if all the new directories are correctly deleted. Also,
try using the software after step 4, to ensure that is works
correctly when installed from a package.Checking your port with portlintPlease use portlint to see if your port
conforms to our guidelines. The portlint
program is part of the ports collection. In particular, your may
want to check if the Makefile is in the right
shape and the package is
named appropriately.Submitting the portFirst, make sure you have read the Do's and Dont's section.Now that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. We do not need your
work directory or the
pkgname.tgz package, so delete them
now. Next, simply include the output of shar `find
port_dir` in a bug report and send it with the
send-pr1 program (see Bug
Reports and General Commentary for more information
about send-pr1. If the uncompressed port is larger than
20KB, you should compress it into a tarfile and use uuencode1 before including it in the bug report (uuencoded
tarfiles are acceptable even if the bug report is smaller than
20KB but are not preferred). Be sure to classify the bug report as
category ports and class
change-request. (Do not mark the report
confidential!)One more time, do not include the original source
distfile, the work directory, or the
package you built with make
package.In the past, we asked you to upload new port submissions
in our ftp site (ftp.freebsd.org). This is no longer
recommended as read access is turned off on that
incoming/ directory of that site due to
the large amount of pirated software showing up there.We will look at your port,
get back to you if necessary, and put it in the
tree. Your name will also appear in the list of “Additional
FreeBSD contributors” on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in DISTDIR.
If fetch cannot find the required files in DISTDIR it will look up the
URL MASTER_SITES,
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
The extract target is run. It looks for your port's
distribution file (typically a gzip'd tarball) in DISTDIR and unpacks it into a temporary subdirectory
specified by WRKDIR
(defaults to work).The patch target is run. First, any patches defined
in PATCHFILES are
applied. Second, if any patches are found in PATCHDIR (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.The configure target is run. This can do any one of
many different things.If it exists,
scripts/configure is run.If HAS_CONFIGURE or
GNU_CONFIGURE
is set,
WRKSRC/configure is
run.If USE_IMAKE is set,
XMKMF
(default: xmkmf
-a) is run.The build target is run. This is responsible for
- descending into the ports' private working directory
+ descending into the port's private working directory
(WRKSRC) and
building it. If USE_GMAKE is set, GNU
make will be used,
otherwise the system make
will be used.The above are the default actions. In addition, you can
define targets pre-something or post-something, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-something. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-something target in
your Makefile.The “main” targets (e.g., extract, configure, etc.) do nothing more than
- make sure all the stages up to that one is completed and
+ make sure all the stages up to that one are completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (foo.tar.gz or
foo.tar.Z) and copy it into
DISTDIR. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, you might want to put a copy on a
reliable ftp or http server that you control (e.g., your home
page). Make sure you set MASTER_SITES to
reflect your choice.If you
cannot find somewhere convenient and reliable to put the distfile
(if you are a FreeBSD committer, you can just put it in your
public_html/ directory on
freefall),
we can “house” it ourselves by putting
- it on ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
+ it on ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as MASTER_SITE_LOCAL. Send mail to
the &a.ports;if you are not sure what to do.If your port's distfile changes all the time for no good
reason, consider putting the distfile in your home page and
listing it as the first MASTER_SITES. This
will prevent users from getting checksum
mismatch errors, and also reduce the workload of
maintainers of our ftp site. Also, if there isonly one master
site for the port, it is recommended that you house a backup at
your site and list it as the second
MASTER_SITES.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
DISTDIR. Do not worry if
- they come from site other than where you got the main source
+ they come from a site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of PATCHFILES below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as “plug-and-play”
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-xx where
xx denotes the sequence in which
the patches will be applied — these are done in
alphabetical order, thus
aa first, ab second and so on. These files
should be stored in PATCHDIR, from where they will be
automatically applied. All patches should be relative to
WRKSRC (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier,
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing WRKSRC/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow “overnight builds” to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).It is also recommended that if there are reasonable default
answers to the questions, you check the
PACKAGE_BUILDING variable and turn off the
interactive script when it is set. This will allow us to build
the packages for CD-ROMs and ftp.Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a sample
Makefile in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in DISTDIR as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set DISTNAME to be the base name of
your port. The default rules expect the distribution file
list (DISTFILES) to be
named DISTNAMEEXTRACT_SUFX which, if it is a normal tarball, is going to be
something like foozolix-1.0.tar.gz for a setting of DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/DISTNAME, e.g. work/foozolix-1.0/.All this behavior can be overridden, of course; it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set DISTFILES explicitly. If only a
subset of DISTFILES are
actual extractable archives, then set them up in EXTRACT_ONLY, which will override
the DISTFILES list when
it comes to extraction, and the rest will be just left in
DISTDIR for later
use.PKGNAMEIf DISTNAME does not conform to our guidelines for a good package
name, you should set the PKGNAME
variable to something better. See the abovementioned guidelines
for more details.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable CATEGORIES. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories and pick the
ones that are suitable for your port.This list also determines where in the ports tree the port
is imported. If you put more than one category here, it is
assumed that the port files will be put in the subdirectory with
the name in the first category. See the categories section for
more discussion about how to pick the right categories.If you port truly belongs to something that is different
from all the existing ones, you can even create a new category
name. In that case, please send mail to the &a.ports; to propose
a new category.There is no error checking for category
names. make package will happily create a
new directory if you mustype the category name, so be
careful!MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in MASTER_SITES. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with FETCH if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set PATCHFILES to the names of the
files and PATCH_SITES to
the URL of the directory that contains them (the format is the
same as MASTER_SITES).If the patch is not relative to the top of the source tree
(i.e., WKRSRC) because it
contains some extra pathnames, set PATCH_DIST_STRIP accordingly.
- For instance, if all the pathnames in the patch has an extra
+ For instance, if all the pathnames in the patch have an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
PATCHFILES. If that is
the case, add the name and the location of the patch tarball
to DISTFILES and
MASTER_SITES. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the PATCHDIR directory and calling it
patch-xx.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to MAINTAINER
on Makefiles section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine. There are also some
pre-supported dependency variables for common cases, plus a few
more to control the behaviour of dependencies.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir:target tuples where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available, and
target is the target to call in
that directory. For example,
LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install
will check for a shared jpeg library with
major version 9, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found. The target part can be
omitted if it is equal to DEPENDS_TARGET
(which defaults to install).The lib part is an argument
given to ldconfig -r | grep -wF. There
shall be no reqular expressions in this variable.The dependency is checked twice, once from within the
extract target and then from within
the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir:target tuples where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available, and
target is the target to call in
that directory. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
will check if the file or directory
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish8.0 is in your search path, and
descend into the x11-toolkits/tk80 subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system. The
target part can be omitted if it is
the same DEPENDS_TARGET.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir:target tuples.
For example,
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.“build” here means everything from extracting to
compilation. The dependency is checked from within the
extract target. The
target part can be omitted if it
is the same as DEPENDS_TARGETFETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir:target tuples. For
example,
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the
fetch target. The
target part can be omitted if it is
the same as DEPENDS_TARGET.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted in addition to having
them installed, then use this variable. This is a list of
dir:target, as there is nothing to check, unlike the previous four. The target part can be omitted if it is the same as DEPENDS_TARGET.Common dependency variablesDefine USE_XLIB=yes if your port
requires the X Window System to be installed (it is implied by
USE_IMAKE). Define
USE_GMAKE=yes if your port requires GNU
make instead of BSD
make. Define
USE_AUTOCONF=yes if your port requires GNU
autoconf to be run. Define USE_QT=yes if
your port uses the latest qt toolkit. Use
USE_PERL5=yes if your port requires version
5 of the perl language. (The last is especially important since
some versions of FreeBSD has perl5 as part of the base system
while others don't.)Notes on dependenciesAs mentioned above, the default target to call when a
dependency is required is
DEPENDS_TARGET. It defaults to
install. This is a user variable; is is
never defined in a port's Makefile. If
your port needs a special way to handle a dependency, use the
:target part of the
*_DEPENDS variables instead of redefining
DEPENDS_TARGET.When you type make clean, its
dependencies are automatically cleaned too. If you do not wish
this to happen, define the variable
NOCLEANDEPENDS in your environment.To depend on another port unconditionally, it is customary
to use the string nonexistent as the first
field of BUILD_DEPENDS or
RUN_DEPENDS. Use this only when you need to
the to get to the source of the other port. You can often save
compilation time by specifying the target too. For
instance
BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract
will always descend to the JPEG port and extract it.Do not use DEPENDS unless there is no
other way the behaviour you want can be accomplished. It will
cause the other port to be always build (and installed, by
default), and the dependency will go into the packages as
- well. If this is really what you need, I recommend you to
+ well. If this is really what you need, I recommend you
write it as BUILD_DEPENDS and
RUN_DEPENDS instead—at least the
intention will be clear.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses
configure, set
HAS_CONFIGURE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes (this implies
HAS_CONFIGURE). If you want to give some
extra arguments to configure (the default
argument list --prefix=${PREFIX} for
GNU configure and empty for non-GNU
configure), set those extra arguments in
CONFIGURE_ARGS. If your package uses GNU
autoconf, set
USE_AUTOCONF=yes. This implies
GNU_CONFIGURE, and will cause
autoconf to be run before
configure.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.
If the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>If your port's source Makefile has
something else than all as the main
build target, set ALL_TARGET
accordingly. Same goes for install and
INSTALL_TARGET.Special considerationsThere are some more things you have to take into account when
you create a port. This section explains the most common of
those.ldconfigIf your port installs a shared library, add a
post-install target to your
Makefile that runs
${LDCONFIG} -m on the directory where
the new library is installed (usually
PREFIX/lib) to register
it into the shared library cache.Also, add a matching @exec /sbin/ldconfig
-m and @unexec /sbin/ldconfig -R
pair to your pkg/PLIST file so that a user
who installed the package can start using teh shared libraru
immediately and deinstallation will not cause the system to
still believe the library is there. These lines should
immediately follow the line for the shared library itself, as
in:
lib/libtvl80.so.1
@exec /sbin/ldconfig -m %D/lib
@unexec /sbin/ldconfig -RNever, ever, ever add a line that says
ldconfig without any arguments to your
Makefile or
pkg/PLIST. This will reset the shared
libraru cache to the contents of /usr/lib
only, and will royally screw up the user's machine ("Help, xinit
does not run anymore after I install this port!"). Anybody who
does this will be shot and cut in 65,536 pieces by a rusty knife
and have is liver chopped out by a bunch of crows and will
eternally rot to death in the deepest bowels of hell (not
necessarily in that order…)ELF support
- Since FreeBSD is moving to ELF from 3.0-release onwards,
+ Since FreeBSD is moving to ELF shortly after 3.0-release,
we need to convert many ports that build shared libraries
to support ELF. Complicating this task is that a 3.0
system can run as both ELF and a.out, and that there will
be one more release (2.2.8) from the 2.2 branch. Below
are the guidelines on how to convert a.out only ports to
support both a.out and ELF compilation.Some part of this list is only applicable during the
conversion, but will be left here for awhile for reference
in case you have come across some old port you wish to
upgrade.Moving a.out libraries out of the wayA.out libraries should be moved out of
/usr/local/lib and similar to an
aout subdirectory. (If you don't move them
out of the way, ELF ports will happily overwrite a.out libraries.)
The move-aout-libs target in the -current
src/Makefile (called from
aout-to-elf) will do this for you. It
will only move a.out libs so it is safe to call it on a system
with both ELF and a.out libs in the standard directories.FormatThe ports tree will build packages in the format the machine
is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending
on what `objformat` returns. Also, once users
move a.out libraries to a subdirectory, building a.out libraries
will be unsupported. (I.e., it may still work if you know what you
are doing, but you are on your own.)If a port only works for a.out, set
BROKEN_ELF to a string describing the reason
why. Such ports will be skipped during a build on an ELF
system.PORTOBJFORMATbsd.port.mk will set
PORTOBJFORMAT to aout or
elf and export it in the environments
CONFIGURE_ENV, SCRIPTS_ENV and
MAKE_ENV. (It's always going to be
aout in -stable). It is also passed to
PLIST_SUB as
PORTOBJFORMAT=${PORTOBJFORMAT}. (See comment
on ldconfig lines below.)The variable is set using this line in
bsd.port.mk:
PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aoutPorts' make processes should use this variable to decide what
to do. However, if the port's configure
script already automatically detects an ELF system, it is not
necessary to refer to PORTOBJFORMAT.Building shared librariesThe following are differences in handling shared
libraries for a.out and ELF.Shared library versionsAn ELF shared library should be called
libfoo.so.M
where M is the single version
number, and an a.out library should be called
libfoo.so.M.N where M is the major version and N is the the minor version number. Do not mix those; never install an ELF shared library called libfoo.so.N.M or an a.out shared library (or symlink) called libfoo.so.N.Linker command linesAssuming cc -shared is used rather than
ld directly, the only difference is that
you need to add
on the command line for ELF.You need to install a symlink from
libfoo.so to
libfoo.so.N to
make ELF linkers happy. Since it should be listed in
PLIST too, and it won't hurt in the a.out
case (some ports even require the link for dynamic loading), you
should just make this link regardless of the setting of
PORTOBJFORMAT.LIB_DEPENDSAll port Makefiles are edited to remove minor numbers from
LIB_DEPENDS, and also to have the regexp
support removed. (E.g., foo\\.1\\.\\(33|40\\)
becomes foo.2.) They will be matched using
grep -wF.PLISTPLIST should contain the short (ELF)
shlib names if the a.out minor number is zero, and the long
(a.out) names otherwise. bsd.port.mk will
automatically add .0 to the end of short shlib
lines if PORTOBJFORMAT equals
aout, and will delete the minor number from
long shlib names if PORTOBJFORMAT equals
elf.In cases where you really need to install shlibs with two
versions on an ELF system or those with one version on an a.out
system (for instance, ports that install compatibility libraries
for other operating systems), define the variable
NO_FILTER_SHLIBS. This will turn off the
editing of PLIST mentioned in the previous
paragraph.ldconfigThe ldconfig line in Makefiles should read:
${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....In PLIST it should read;
@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ...
@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -RThis is to ensure that the correct ldconfig
will be called depending on the format of the package, not the
default format of the system.MASTERDIRIf your port needs to build slightly different versions of
packages by having a variable (for instance, resolution, or paper
size) take different values, create one subdirectory per package
to make it easier forusers to see what to do, but try to share as
many files as possible between ports. Typically you only need a
very short Makefile in all but one of the
directories if you use variables cleverly. In the sole
Makefiles, you can use
MASTERDIR to specify the directory where the
rest of the files are. Also, use a variable as part of
PKGNAME
so the packages will have different names.This will be best demonstrated by an example. This is part of
japanese/xdvi300/Makefile;
PKGNAME= ja-xdvi${RESOLUTION}-17
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endifjapanese/xdvi300 also has all the regular
patches, package files, etc. If you type make
there, it will take the default value for the resolution (300) and
build the port normally.As for other resolutions, this is the
entirexdvi118/Makefile;
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile(xdvi240/Makefile and
xdvi400/Makefile are similar). The
MASTERDIR definition tells
bsd.port.mk that the refulat set of
subdirectories like PATCHDIR and
PKGDIR are to be found under
xdvi300. The
RESOLUTION=118 line will override the
RESOLUTION=300 line in
xdvi300/Makefile and the port will be built
with resolution set to 118.Shared library versionsFirst, please read our policy
on shared library versioning to understand
what to do with shared library versions in general. Do
not blindly assume software authors know what they are
doing; many of them do not. It is very important that
these details are carefully considered, as we have quite a
unique situation where we are trying to have dozens of
potentially incompatible software pairs co-exist.
Careless port imports have caused great trouble regarding
shared libraries in the past (ever wondered why the port
jpeg-6b has a shared library version of 9.0?).
If in doubt, send a message to the &a.ports;. Most of the
time, your job ends by determining the right shared
library version and making appropriate patches to
implement it.However, if there is a port which is a different version
of the same software already in the tree, the situation is
much more complex. In short, the FreeBSD implementation
does not allow the user to specify to the linker which
version of shared library to link against (the linker will
always pick the highest numbered version). This means, if
there is a libfoo.so.3.2 and libfoo.so.4.0 in
the system, there is no way to tell the linker to link a
particular application to libfoo.so.3.2. It is
essentially completely overshadowed in terms of
compilation-time linkage. In this case, the only solution
is to rename the base part of the shared library. For
instance, change libfoo.so.4.0 to
libfoo4.so.1.0 so both version 3.2 and 4.0 can be
linked from other ports.ManpagesThe MAN[1-9LN] variables will automatically
add any manpages to pkg/PLIST (this means you
must not list manpages in the
PLIST—see generating PLIST for more). It
also makes the install stage automatically compress or uncompress
manpages depending on the setting of
NOMANCOMPRESS in
/etc/make.conf.To specify whether the manpages are compressed upon
installation, use the MANCOMPRESSED variable.
This variable can take three values, yes,
no and maybe.
yes means manpages are already installed
compressed, no means they are not, and
maybe means the software already respects the
value of NOMANCOMPRESS so
bsd.port.mk does not have to do anything
special.MANCOMPRESSED is automatically set to
yes if USE_IMAKE is set and
NO_INSTALL_MANPAGES is not set, and to
no otherwise. You don't have to explicitly
define it unless the default is not suitable for your port.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages in
certain sections go in a non-standard place, such as some Perl
modules ports, you can set individual man paths using
MANsectPREFIX (where
sect is one of 1-9,
L or N).If your manpages go to language-specific subdirectories, set
the name of the languages to MANLANG. The
value of this variable defaults to "" (i.e.,
English only).Here is an example that puts it all together.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yesThis states that six files are installed by this port;
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gzPorts that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is
a free clone reported to be able to run many applications in
x11-toolkits/lesstif) to compile. Since
it is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically (for people who are compiling from the port) or
statically (for people who distribute packages).REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.MOTIFLIBThis variable will be set by
bsd.port.mk to be the appropriate reference
to the Motif library. Please patch the source to use this
wherever the Motif library is referenced in the
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its Makefile
or Imakefile, simply substitute
${MOTIFLIB} for
it.If the port uses XmClientLibs
in its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands to
-L/usr/X11R6/lib -lXm or
/usr/X11R6/lib/libXm.a, so there is no need
to add -L or -l in
front.X11 fontsIf your port installs fonts for the X Window system, put them
in
X11BASE/lib/X11/fonts/local.
This directory is new to XFree86 release 3.3.3. If it does not
exist, please create it, and print out a message urging the user
to update their XFree86 to 3.3.3 or newer, or at least add this
directory to the font path in
/etc/XF86Config.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info
to add and delete entries to the dir file. If
your port installs any info documents, please follow this
instructions so your port/package will correctly update the user's
PREFIX/info/dir
file. (Sorry for the length of this section, but is it imperative
to weave all the info files together. If done correctly, it will
produce a beautiful listing, so please bear
with me!First, this is what you (as a porter) need to know&prompt.user; install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
:
--entry=TEXT Insert TEXT as an Info directory entry.
:
--section=SEC Put this file's entries in section SEC of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995
+++ ./man/vip.texi Tue May 20 01:28:33 1997
@@ -2,6 +2,10 @@
@setfilename ../info/vip
@settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry
+* VIP: (vip). A VI-emulation for Emacs.
+@end direntry
@iftex
@finalout
:The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/04/15 06:32:12
@@ -15,9 +15,6 @@
man/man1/emacs.1.gz
man/man1/etags.1.gz
man/man1/ctags.1.gz
-@unexec cp %D/info/dir %D/info/dir.bak
-info/dir
-@unexec cp %D/info/dir.bak %D/info/dir
info/cl
info/cl-1
info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+ if [ ! -f ${PREFIX}/info/dir ]; then \
+ ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \
+ fi
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/05/20 10:25:12 1.17
@@ -16,7 +14,15 @@
man/man1/etags.1.gz
man/man1/ctags.1.gz
+@unexec install-info --delete %D/info/emacs %D/info/dir
:
+@unexec install-info --delete %D/info/ccmode %D/info/dir
info/cl
info/cl-1
@@ -87,6 +94,18 @@
info/viper-3
info/viper-4
+@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
+@exec install-info %D/info/emacs %D/info/dir
:
+@exec install-info %D/info/ccmode %D/info/dir
libexec/emacs/19.34/i386--freebsd/cvtmail
libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :). Check the dir file before and after each
step.The pkg/ subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.MESSAGEIf you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capability is often useful to display additional installation
steps to be taken after a pkg_add or to display
licensing information.The pkg/MESSAGE file does not need to
be added to pkg/PLIST. Also, it will not get
automatically printed if the user is using the port, not the
package, so you should probably display it from the
post-install target yourself.INSTALL
- If your port needs execute commands when the binary package is
- installed with pkg_add you can do with via the
+ If your port needs to execute commands when the binary package is
+ installed with pkg_add you can do this via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice by
pkg_add. The first time will as
INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be
tested to determine which mode the script is being run in. The
PKG_PREFIX environmental variable will be set to
the package installation directory. See pkg_add1 for additional
information.This script is not run automatically if you install the port
with make install. If you are depending on
- it being run, you will have to explicitly call it on your port's
+ it being run, you will have to explicitly call it from your port's
Makefile.REQIf your port needs to determine if it should install or not,
you can create a pkg/REQ
“requirements” script. It will be invoked
automatically at installation/deinstallation time to determine
whether or not installation/deinstallation should proceed.Changing PLIST based on make variablesSome ports, particularly the p5- ports, need to change their
PLIST depending on what options they are
configured with (or version of perl, in the case of p5- ports). To
make this easy, any instances in the PLIST of
%%OSREL%%, %%PERL_VER%%, and
%%PERL_VERSION%% will be substituted for
appropriately. The value of %%OSREL%% is the
numeric revision of the operating system (e.g.,
2.2.7). %%PERL_VERSION%% is
the full version number of perl (e.g., 5.00502)
and %%PERL_VER%% is the perl version number
minus the patchlevel (e.g., 5.005).If you need to make other substitutions, you can set the
PLIST_SUB variable with a list of
VAR=VALUE
pairs and instances of
%%VAR%%' will be
substituted with VALUE in the
PLIST.For instance, if you have a port that installs many files in
a version-specific subdirectory, you can put something
like
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
in the Makefile and use
%%OCTAVE_VERSION%% wherever the version shows
up in PLIST. That way, when you upgrade the
port, you will not have to change dozens (or in some cases,
hundreds) of lines in the PLIST.This substitution (as well as addition of any man pages) will be done
between the do-install and
post-install targets, by reading from
PLIST and writing to
TMPPLIST (default:
WRKDIR/.PLIST.mktmp). So
if your port builds PLIST on the fly, do so in
or before do-install. Also, if your port
needs to edit the resulting file, do so in
post-install to a file named
TMPPLIST.
+
+
+ Changing the names of files in the
+ pkg subdirectory
+
+ All the filenames in the pkg subdirectory
+ are defined using variables so you can change them in your
+ Makefile if need be. This is especially useful when you
+ are sharing the same pkg subdirectory among
+ several ports or have to write to one of the above files (see
+ writing to places other than
+ WRKDIR for why it is a bad idea to
+ write directly in to the pkg
+ subdirectory.
+
+ Here is a list of variable names and their default
+ values.
+
+
+
+
+
+ Variable
+ Default value
+
+
+
+
+
+ COMMENT
+ ${PKGDIR}/DESCR
+
+
+
+ DESCR
+ ${PKGDIR}/DESCR
+
+
+
+ PLIST
+ ${PKGDIR}/PLIST
+
+
+
+ PKGINSTALL
+ ${PKGDIR}/PKGINSTALL
+
+
+
+ PKGDEINSTALL
+ ${PKGDIR}/PKGDEINSTALL
+
+
+
+ PKGREQ
+ ${PKGDIR}/REQ
+
+
+
+ PKGMESSAGE
+ ${PKGDIR}/MESSAGE
+
+
+
+
+
+ Please change these variables rather than overriding
+ PKG_ARGS. If you change
+ PKG_ARGS, those files will not correctly be
+ installed in /var/db/pkg upon install from a
+ port.
+
-
+
Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
- can do with them vary a lot, depending on the exact wordings of
+ can do with them varies a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a “do not sell for profit” type of
license, set the variable NO_CDROM to a
string describing the reason why. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE to a string describing the
reason why. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a “no commercial use” license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (e.g., if your modified port
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category ports). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.You should check your own port
against this list, but you can also check ports in the PR
database that others have submitted. Submit any comments on
ports you check as described in Bug
Reports and General Commentary. Checking ports in
the PR database will both make it faster for us to commit them,
and prove that you know what you are doing.Strip BinariesDo strip binaries. If the original source already strips the
binaries, fine; otherwise you should add a
post-install rule to to it yourself. Here is an
example;
post-install:
strip ${PREFIX}/bin/xdlUse the file1 command on the installed executable to check
whether the binary is stripped or not. If it does not say
not stripped, it is stripped.INSTALL_* macrosDo use the macros provided in bsd.port.mk
to ensure correct modes and ownership of files in your own
*-install targets. They are:INSTALL_PROGRAM is a command to install
binary executables.INSTALL_SCRIPT is a command to install
executable scripts.INSTALL_DATA is a command to install
sharable data.INSTALL_MAN is a command to install
manpages and other documentation (it doesn't compress
anything).These are basically the install command
with all the appropriate flags. See below for an example on how
to use them.
+
+
+ WRKDIR
+
+ Do not write anything to files outside
+ WRKDIR. WRKDIR is the only
+ place that is guaranteed to be writable during the port build (see
+ compiling ports from CDROM for an
+ example of building ports from a read-only tree). If you need to
+ modigy some file in PKGDIR, do so by redefining a variable, not by
+ writing over it.
+
+
+
+ WRKDIRPREFIX
+
+ Make sure your port honors
+ WRKDIRPREFIX. Most ports don't have to worry
+ about this. In particular, if you are referring to a
+ WRKDIR of another port, note that the correct
+ location is
+ WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such.
+
+ Also, if you are defining WRKDIR yourself,
+ make sure you prepend
+ ${WKRDIRPREFIX}${.CURDIR} in the
+ front.
+ Differentiating operating systems and OS versionsYou may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as general
as possible so that we can back-port code to FreeBSD 1.x systems
and cross-port to other BSD systems such as 4.4BSD from CSRG,
BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file is
already included; if not, add the code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endifto the proper place in the .c file. We
- believe that every system that defines these to symbols has
+ believe that every system that defines these two symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to the
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile
for this method.Once you have sys/param.h
included, you may use:
#if (defined(BSD) && (BSD >= 199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:
#if (defined(BSD) && (BSD >= 199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is
199506 for the 4.4BSD-Lite2 code base. This is
stated for informational purposes only. It should not be used to
- distinguish between version of FreeBSD based only on 4.4-Lite vs.
+ distinguish between versions of FreeBSD based only on 4.4-Lite vs.
versions that have merged in changes from 4.4-Lite2. The
__FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
only affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endifRelease_FreeBSD_version2.0-RELEASE1194112.1-currents199501, 1995032.0.5-RELEASE1995042.2-current before 2.11995082.1.0-RELEASE1995112.2-current before 2.1.51995122.1.5-RELEASE1996072.2-current before 2.1.61996082.1.6-RELEASE1996122.1.7-RELEASE1996122.2-RELEASE2200002.2.1-RELEASE220000 (no change)2.2-STABLE after 2.2.1-RELEASE220000 (no change)2.2-STABLE after texinfo-3.92210012.2-STABLE after top2210022.2.2-RELEASE2220002.2-STABLE after 2.2.2-RELEASE2220012.2.5-RELEASE2250002.2-STABLE after 2.2.5-RELEASE2250012.2-STABLE after ldconfig -R merge2250022.2.6-RELEASE2260002.2.7-RELEASE2270002.2-STABLE after 2.2.7-RELEASE2270012.2-STABLE after semctl(2) change2270022.2.8-RELEASE2280002.2-STABLE after 2.2.8-RELEASE2280013.0-current before mount(2) change3000003.0-current after mount(2) change3000013.0-current after semctl(2) change3000023.0-current after ioctl arg changes3000033.0-current after ELF conversion3000043.0-RELEASE3000053.0-current after 3.0-RELEASE300006
+
+
+ 3.0-stable after 3/4 branch
+ 300007
+
+
+
+ 3.1-RELEASE
+ 310000
+
+
+
+ 3.1-stable after 3.1-RELEASE
+ 310001
+
+
+
+ 4.0-current after 3/4 branch
+ 400000
+ Note that 2.2-STABLE sometimes identifies itself as
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Writing something after
bsd.port.mkDo not write anything after the .include
<bsd.port.mk> line. it usually can be avoided by
including bsd.port.pre.mk somewhere in the
middle of your Makefile and
bsd.port.post.mk at the end.You need to include either the
pre.mk/post.mk pair or
bsd.port.mk only; don't mix these
two.bsd.port.pre.mk only defines a few
variables, which can be used in tests in the
Makefile,
bsd.port.post.mk defines the rest.Here are some important variables defined in
bsd.port.pre.mk (this is not the complete
list, please read bsd.port.mk for the
complete list).VariableDescriptionARCHThe architecture as returned by uname
-m (e.g., i386)OPSYSThe operating system type, as returned by
uname -s (e.g.,
FreeBSD)OSRELThe release version of the operating system (e.g.,
2.1.5 or
2.2.7)OSVERSIONThe numeric version of the operating system, same as
__FreeBSD_version.PORTOBJFORMATThe object format of the system
(aout or elfLOCALBASEThe base of the “local” tree (e.g.,
/usr/local/)X11BASEThe base of the “X11” tree (e.g.,
/usr/X11R6)PREFIXWhere the port installs itself (see more on
PREFIX).If you have to define the variables
USE_IMAKE, USE_X_PREFIX,
or MASTERDIR, do so before including
bsd.port.pre.mk.Here are some examples of things you can write after
bsd.port.pre.mk;
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endifInstall additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
PREFIX/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means PKGNAME minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole PKGNAME.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)Also you can use the pkg/MESSAGE file to
display messages upon installation. See the using
pkg/MESSAGE section for
details.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
Makefile), set DIST_SUBDIR to the name of the
port (PKGNAME without the
version part should work fine). This will change DISTDIR from the default
/usr/ports/distfiles to
/usr/ports/distfiles/DIST_SUBDIR,
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting DISTDIR explicitly in your
Makefile will not accomplish this, so please use DIST_SUBDIR.)This does not affect the MASTER_SITES you define in your
Makefile.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
NO_PACKAGE is
set.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. If you had to edit
configure.in and run
autoconf to regenerate
configure, do not take the diffs of
configure (it often grows to a few thousand
lines!); define USE_AUTOCONF=yes and take the
diffsof configure.in.Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resulting diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to PREFIX. (The value of this
variable will be set to LOCALBASE (default
/usr/local), unless USE_X_PREFIX or USE_IMAKE is set, in which case it
will be X11BASE (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read PREFIX, as this
variable is automatically passed down to every stage of the
build and install processes.Do not set USE_X_PREFIX unless your port
truly require it (i.e., it links against X libs or it needs to
reference files in X11BASE).The variable PREFIX
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles.Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\"
or
-DPAGER=\"${LOCALBASE}/bin/less\"
if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of PREFIX. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
- details, the rule governing /usr pretty
- much applies to /usr/local too. The
+ details, the rules governing /usr pretty
+ much apply to /usr/local too. The
exception are ports dealing with USENET “news”. They may use
PREFIX/news as a destination for
their files.Cleaning up empty directoriesDo make your ports clean up after themselves when they are
deinstalled. This is usually accomplished by adding
@dirrm lines for all directories that are
specifically created by the port. You need to delete
subdirectories before you can delete parent directories.
:
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
:
@dirrm lib/X11/oneko/pixmals
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/onekoHowever, sometimes @dirrm will give you
errors because other ports also share the same subdirectory. You
can call rmdir from @unexec
to remove only empty directories without warning.
@unexec rmdir %D/share/doc/gimp 2>/dev/null || trueThis will neither print any error messages nor cause
pkg_delete to exit abnormally even if
PREFIX/share/doc/gimp is
not empty due to other ports installing some files in there.UIDsIf your port requires a certain user to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at net/cvsup-mirror
for an example.If your port must use the same user/group ID number when it is
installed a binarypackage as when it was compiled, then you mus
choose a free UID from 50 to 99 and register it below. Look at
japanese/Wnn for an example.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/shPlease include a notice when you submit a port (or an
upgrade) that reserves a new UID or GID in this range. This allows
us to keep the list of reserved IDs up to date.Do things rationallyThe Makefile should do things simply and
reasonably. If you can make it a couple of lines shorter or more
readable, then do so. Examples include using a make
.if construct instead of a shell
if construct, not redefining
do-extract if you can redefine
EXTRACT* instead, and using
GNU_CONFIGURE instead of
CONFIGURE_ARGS +=
--prefix=${PREFIX}.Respect CFLAGSThe port should respect the CFLAGS
variable. If it doesn't, please add NO_PACKAGE=ignores
cflags to the Makefile.Configuration filesIf your port requires some configuration files in
PREFIX/etc, do
not just install them and list them in
pkg/PLIST. That will cause
pkg_delete to delete files carefully edited by
the user and a new installation to wipe them out.Instead, install sample files with a suffix
(filename.sample
will work well) and print out a message pointing out that the
user has to copy and edit the file before the software can be made
to work.PortlintDo check your work with portlint
before you submit or commit it.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code. This
will only make your job that much easier for the next
release.MiscellaneaThe files pkg/DESCR,
pkg/COMMENT, and
pkg/PLIST should each be double-checked. If
you are reviewing a port and feel they can be worded better, do
so.Don't copy more copies of the GNU General Public License into
our system, please.Please be careful to note any legal issues! Don't let us
illegally distribute software!If you are stuck…Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample MakefileHere is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). This format is
designed so that the most important information is easy to
locate. We recommend that you use portlint to check the Makefile.
[the header...just to make it easier for us to identify the ports.]
# New ports collection makefile for: xdvi
[the version required header should updated when upgrading a port.]
# Version required: pl18 [things like "1.5alpha" are fine here too]
[this is the date when the first version of this Makefile was created.
Never change this when doing an update of the port.]
# Date created: 26 May 1995
[this is the person who did the original port to FreeBSD, in particular, the
person who wrote the first version of this Makefile. Remember, this should
not be changed when upgrading the port later.]
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
#
# $Id$
[ ^^^^ This will be automatically replaced with RCS ID string by CVS
when it is committed to our repository.]
#
[section to describe the port itself and the master site - DISTNAME
is always first, followed by PKGNAME (if necessary), CATEGORIES,
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be specified too.]
DISTNAME= xdvi
PKGNAME= xdvi-pl18
CATEGORIES= print
[do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros]
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz" form]
EXTRACT_SUFX= .tar.Z
[section for distributed patches -- can be empty]
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[maintainer; *mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug reports - this
person should be the porter or someone who can forward questions to the
original porter reasonably promptly. If you really do not want to have
your address here, set it to "ports@FreeBSD.ORG".]
MAINTAINER= asami@FreeBSD.ORG
[dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm
[this section is for other standard bsd.port.mk variables that do not
belong to any of the above]
[If it asks questions during configure, build, install...]
IS_INTERACTIVE= yes
[If it extracts to a directory other than ${DISTNAME}...]
WRKSRC= ${WRKDIR}/xdvi-new
[If the distributed patches were not made relative to ${WRKSRC}, you
may need to tweak this]
PATCH_DIST_STRIP= -p1
[If it requires a "configure" script generated by GNU autoconf to be run]
GNU_CONFIGURE= yes
[If it requires GNU make, not /usr/bin/make, to build...]
USE_GMAKE= yes
[If it is an X application and requires "xmkmf -a" to be run...]
USE_IMAKE= yes
[et cetera.]
[non-standard variables to be used in the rules below]
MY_FAVORITE_RESPONSE= "yeah, right"
[then the special rules, in the order they are called]
pre-fetch:
i go fetch something, yeah
post-patch:
i need to do something after patch, great
pre-install:
and then some more stuff before installing, wow
[and then the epilogue]
.include <bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like language-name-compiled.specifics-version.numbers.If your DISTNAME
doesn't look like that, set PKGNAME to something in that
format.FreeBSD strives to support the native language of its
users. The language- part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
ja for Japanese, ru for Russian, vi for Vietnamese,
zh for Chinese, ko for Korean and de for German.The name part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a port of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the capital letters are
important to the name (for example, with one-letter names
like R or V) you may use capital letters at your discretion.
There is a tradition of naming Perl 5 modules by prepending
p5- and converting the double-colon separator to a hyphen;
for example, the Data::Dumper module becomes
p5-Data-Dumper. If the software in question has numbers,
hyphens, or underscores in its name, you may include them as
well (like kinput2).If the port can be built with different hardcoded
defaults (usually part of the directory name in a
family of ports), the
-compiled.specifics part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string pl (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a DISTNAME into a suitable PKGNAME:Distribution NamePackage NameReasonmule-2.2.2.mule-2.2.2No changes requiredXFree86-3.1.2XFree86-3.1.2No changes requiredEmiClock-1.0.2emiclock-1.0.2No uppercase names for single programsgmod1.4gmod-1.4Need a hyphen before version numbersxmris.4.0.2xmris-4.0.2Need a hyphen before version numbersrdist-1.3alphardist-1.3aNo strings like alpha
allowedes-0.9-beta1es-0.9b1No strings like beta
allowedv3.3beta021.srctiff-3.3What the heck was that anyway?tvtwmtvtwm-pl11Version string always requiredpiewmpiewm-1.0Version string always requiredxvgr-2.10pl1xvgr-2.10.1pl allowed only when no
major/minor version numbersgawk-2.15.6ja-gawk-2.15.6Japanese language versionpsutils-1.13psutils-letter-1.13Papersize hardcoded at package build timepkfontspkfonts300-1.0Package for 300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to 1.0 (like the piewm example above). Otherwise, ask the
original author or use the date string (yy.mm.dd) as the
version.CategoriesAs you already know, ports are classified in several
categories. But for this to wor, it is important that porters and
users understand what each category and how we deicde what to put in
each category.Current list of categoriesFirst, this is the current list of port categories. Those
marked with an asterisk (*) are
virtual categories—those that do not
have a corresponding subdirectory in the ports tree.For non-virtual categories, you will find a one-line
description in the pkg/COMMENT file in that
subdirectory (e.g.,
archivers/pkg/COMMENT).CategoryDescription
+
+ afterstep*
+ Ports to support AfterStep window manager
+
+
archiversArchiving tools.astroAstronomical ports.audioSound support.benchmarksBenchmarking utilities.biologyBiology-related software.cadComputer aided design tools.chineseChinese language support.commsCommunication software. Mostly software to talk to
your serial port.convertersCharacter code converters.databasesDatabases.deskutilsThings that used to be on the desktop before
computers were invented.develDevelopment utilities. Do not put libraries here just
because they are libraries—unless they truly don't
belong to anywhere else, they shouldn't be in this
category.editorsGeneral editors. Specialized editors go in the
section for those tools (e.g., a mathematical-formula
editor will go in math).elispEmacs-lisp ports.emulatorsEmulators for other operating systems. Terminal
emulators do not belong
here—X-based ones should go to
x11 and text-based ones to either
comms or misc,
depending on the exact functionality.gamesGames.germanGerman language support.graphicsGraphics utilities.japaneseJapanese language support.kde*Ports that form the K Desktop Environment
(kde).koreanKorean language support.langProgramming languages.mailMail software.mathNumerical computation software and other utilities
for mathematics.mboneMBone applications.miscMiscellaneous utilities—basically things that
doesn't belong to anywhere else. This is the only category
that should not appear with any other non-virtual
category. If you have misc with
something else in your CATEGORIES line,
that means you can safely delete misc
and just put the port in that other subdirectory!netMiscellaneous networking software.newsUSENET news software.offix*Ports from the OffiX suite.
- perl5*
- Ports that require perl version 5 to run.
+ palm
+ Software support for the 3Com Palm(tm) series.
-
+
- pilot*
- Software to use with the 3Com PalmPilot.
+ perl5*
+ Ports that require perl version 5 to run.
- plan9
+ plan9*Various programs from Plan9.printPrinting software. Desktop publishing tools
(previewers, etc.) belong here too.python*Software written in python.russianRussian language support.securitySecurity utilities.shellsCommand line shells.sysutilsSystem utilities.tcl75*Ports that use tcl version 7.5 to run.tcl76*Ports that use tcl version 7.6 to run.tcl80*Ports that use tcl version 8.0 to run.tcl81*Ports that use tcl version 8.1 to run.textprocText processing utilities. It does not include
desktop publishing tools, which go to print/.tk41*Ports that use tk version 4.1 to run.tk42*Ports that use tk version 4.2 to run.tk80*Ports that use tk version 8.0 to run.tk81*Ports that use tk version 8.1 to run.vietnameseVietnamese language support.
+
+ windowmaker*
+ Ports to support the WindowMaker window
+ manager
+
+
wwwSoftware related to the World Wide Web. HTML language
support belong here too.x11The X window system and friends. This category is
only for software that directly support the window system.
Do not put regular X applications here. If your port is
an X application, define USE_XLIB
(implied by USE_IMAKE) and put it in
appropriate categories. Also, many of them go into other
x11-* categories (see below).x11-clocksX11 clocks.x11-fmX11 file managers.x11-fontsX11 fonts and font utilities.x11-toolkitsX11 toolkits.x11-wmX11 window managers.Choosing the right categoryAs many of the categories overlap, you often have to choose
which of the categories should be the primary category of your
port. There are several rules that govern this usse. Here is the
list of priorities, in decreasing order of precedence.Language specific categories alwasys come first. For
example, if your port installs Japanese X11 fonts, then your
CATEGORIES line would read
japanese x11.Specific categories win over less-specific ones. For
instance, an HTML editor should be listed as www
editors, not the other way around. Also, you don't
need to list net when the port belongs to
either of mail, mbone,
news, security, or
www.x11 is used as a secondary category
only when the primary category is a natural language. In
particular, you should not put x11 in the
category line for X applications.If your port truly does not belong anywhere else, put it
in misc.If you are not sure about the category, please put a comment
to that effect in your send-pr submission so we
can discuss it before import it. (If you are a committer, send a
note &a.ports; so we can discuss it first—too often new
ports are imported to a wrong category only to be moved right
away.)Changes to this document and the ports systemIf you maintain a lot of ports, you should consider following
the &a.ports;. Important changes to
the way ports work will be announced there. You can always
find more detailed information on the latest changes by
looking at
the bsd.port.mk CVS log.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)
diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
index 00fcb1dc43..ccc28daebc 100644
--- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
@@ -1,1710 +1,1711 @@
SecurityDES, MD5, and CryptContributed by &a.wollman;24 September
1995.In order to protect the security of passwords on UN*X systems
from being easily exposed, passwords have traditionally been
scrambled in some way. Starting with Bell Labs' Seventh Edition
Unix, passwords were encrypted using what the security people call a
“one-way hash function”. That is to say, the password is
transformed in such a way that the original password cannot be
regained except by brute-force searching the space of possible
passwords. Unfortunately, the only secure method that was available
to the AT&T researchers at the time was based on DES, the Data
Encryption Standard. This causes only minimal difficulty for
commercial vendors, but is a serious problem for an operating system
like FreeBSD where all the source code is freely available, because
national governments in many places like to place restrictions on
cross-border transport of DES and other encryption software.So, the FreeBSD team was faced with a dilemma: how could we
provide compatibility with all those UNIX systems out there while
still not running afoul of the law? We decided to take a dual-track
approach: we would make distributions which contained only a
non-regulated password scrambler, and then provide as a separate
add-on library the DES-based password hash. The password-scrambling
function was moved out of the C library to a separate library,
called libcrypt because the name of
the C function to implement it is crypt. In FreeBSD 1.x and some pre-release
2.0 snapshots, the non-regulated scrambler uses an insecure function
written by Nate Williams; in subsequent releases this was replaced
by a mechanism using the RSA Data Security, Inc., MD5 one-way hash
function. Because neither of these functions involve encryption,
they are believed to be exportable from the US and importable into
many other countries.Meanwhile, work was also underway on the DES-based password hash
function. First, a version of the crypt function which was written outside the
US was imported, thus synchronizing the US and non-US code. Then,
the library was modified and split into two; the DES libcrypt contains only the code involved in
performing the one-way password hash, and a separate libcipher was created with the entry points
to actually perform encryption. The code was partitioned in this
way to make it easier to get an export license for the compiled
library.Recognizing your crypt
mechanismIt is fairly easy to recognize whether a particular password
string was created using the DES- or MD5-based hash function. MD5
password strings always begin with the characters $1$. DES password strings do not
have any particular identifying characteristics, but they are
shorter than MD5 passwords, and are coded in a 64-character
alphabet which does not include the $ character, so a relatively short
string which doesn't begin with a dollar sign is very likely a DES
password.Determining which library is being used on your system is
fairly easy for most programs, except for those like init which are statically linked. (For
those programs, the only way is to try them on a known password
and see if it works.) Programs which use crypt are linked against libcrypt, which for each type of library is
a symbolic link to the appropriate implementation. For example,
on a system using the DES versions:&prompt.user; cd /usr/lib
&prompt.user; ls -l /usr/lib/libcrypt*
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.aOn a system using the MD5-based libraries, the same links will
be present, but the target will be libscrypt
rather than libdescrypt.S/KeyContributed by &a.wollman;25 September
1995.S/Key is a one-time password scheme based on a one-way hash
function (in our version, this is MD4 for compatibility; other
versions have used MD5 and DES-MAC). S/Key has been a standard part
of all FreeBSD distributions since version 1.1.5, and is also
implemented on a large and growing number of other systems. S/Key
is a registered trademark of Bell Communications Research,
Inc.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual UNIX-style
or Kerberos password; we will call this a “UNIX password”. The
second sort is the one-time password which is generated by the S/Key
key program and accepted by the
keyinit program and the login
prompt; we will call this a “one-time password”. The final sort
of password is the secret password which you give to the key program (and sometimes the keyinit program) which it uses to generate
one-time passwords; we will call it a “secret password” or just
unqualified “password”.The secret password does not necessarily have anything to do
with your UNIX password (while they can be the same, this is not
recommended). While UNIX passwords are limited to eight characters
in length, your S/Key secret password can be as long as you like; I
use seven-word phrases. In general, the S/Key system operates
completely independently of the UNIX password system.There are in addition two other sorts of data involved in the
S/Key system; one is called the “seed” or (confusingly) “key”,
and consists of two letters and five digits, and the other is the
“iteration count” and is a number between 100 and 1. S/Key
constructs a one-time password from these components by
concatenating the seed and the secret password, then applying a
one-way hash (the RSA Data Security, Inc., MD4 secure hash function)
iteration-count times, and turning the result into six short English
words. The login and su programs keep track of the last one-time
password used, and the user is authenticated if the hash of the
user-provided password is equal to the previous password. Because a
one-way hash function is used, it is not possible to generate future
one-time passwords having overheard one which was successfully used;
the iteration count is decremented after each successful login to
keep the user and login program in sync. (When you get the
iteration count down to 1, it is time to reinitialize S/Key.)There are four programs involved in the S/Key system which we
will discuss below. The key program
accepts an iteration count, a seed, and a secret password, and
generates a one-time password. The keyinit program is used to initialized S/Key,
and to change passwords, iteration counts, or seeds; it takes either
a secret password, or an iteration count, seed, and one-time
password. The keyinfo program
examines the /etc/skeykeys file and prints out
the invoking user's current iteration count and seed. Finally, the
login and su programs contain the necessary logic to
accept S/Key one-time passwords for authentication. The login program is also capable of disallowing
the use of UNIX passwords on connections coming from specified
addresses.There are four different sorts of operations we will cover. The
first is using the keyinit program
over a secure connection to set up S/Key for the first time, or to
change your password or seed. The second operation is using the
keyinit program over an insecure
connection, in conjunction with the key program over a secure connection, to do
the same. The third is using the key program to log in over an insecure
connection. The fourth is using the key program to generate a number of keys
which can be written down or printed out to carry with you when
going to some location without secure connections to anywhere (like
at a conference).Secure connection initializationTo initialize S/Key, change your password, or change your seed
while logged in over a secure connection (e.g., on the console of
a machine), use the keyinit
command without any parameters while logged in as yourself:&prompt.user; keyinit
Updating wollman: ) these will not appear if you
Old key: ha73895 ) have not used S/Key before
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password: ) I typed my pass phrase here
Again secret password: ) I typed it again ID
wollman s/key is 99 ha73896 ) discussed below SAG
HAS FONT GOUT FATE BOOM )There is a lot of information here. At theEnter secret
password: prompt, you should enter some password or phrase (I use
phrases of minimum seven words) which will be needed to generate
login keys. The line starting `ID' gives the parameters of your
particular S/Key instance: your login name, the iteration count,
and seed. When logging in with S/Key, the system will remember
these parameters and present them back to you so you do not have
to remember them. The last line gives the particular one-time
password which corresponds to those parameters and your secret
password; if you were to re-login immediately, this one-time
password is the one you would use.Insecure connection initializationTo initialize S/Key or change your password or seed over an
insecure connection, you will need to already have a secure
connection to some place where you can run the key program; this might be in the form of a
desk accessory on a Macintosh, or a shell prompt on a machine you
trust (we will show the latter). You will also need to make up an
iteration count (100 is probably a good value), and you may make
up your own seed or use a randomly-generated one. Over on the
insecure connection (to the machine you are initializing), use the
keyinit -s command:&prompt.user; keyinit -s
Updating wollman: Old key: kh94741
Reminder you need the 6 English words from the skey command.
Enter sequence count from 1 to 9999:100 ) I typed this
Enter new key [default kh94742]:
s/key 100 kh94742To accept the default seed (which the keyinit program
confusingly calls a key), press return. Then move over to your
secure connection or S/Key desk accessory, and give it the same
parameters:&prompt.user; key 100 kh94742
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
HULL NAY YANG TREE TOUT VETONow switch back over to the insecure connection, and copy the
one-time password generated by key
over to the keyinit
program:s/key access password:HULL NAY YANG TREE TOUT VETO
ID wollman s/key is 100 kh94742
HULL NAY YANG TREE TOUT VETOThe rest of the description from the previous section applies
here as well.Diversion: a login promptBefore explaining how to generate one-time passwords, we
should go over an S/Key login prompt:&prompt.user; telnet himalia
Trying 18.26.0.186...
Connected to himalia.lcs.mit.edu.
Escape character is '^]'.
s/key 92 hi52030
Password:Note that, before prompting for a password, the login program
prints out the iteration number and seed which you will need in
order to generate the appropriate key. You will also find a
useful feature (not shown here): if you press return at the
password prompt, the login program will turn echo on, so you can
see what you are typing. This can be extremely useful if you are
attempting to type in an S/Key by hand, such as from a
printout.If this machine were configured to disallow UNIX passwords
over a connection from my machine, the prompt would have also
included the annotation (s/key
required), indicating that only S/Key one-time
passwords will be accepted.Generating a single one-time passwordNow, to generate the one-time password needed to answer this
login prompt, we use a trusted machine and the key program. (There are versions of the
key program from DOS and Windows
machines, and there is an S/Key desk accessory for Macintosh
computers as well.) The command-line key program takes as its parameters the
iteration count and seed; you can cut-and-paste right from the
login prompt starting at key to
the end of the line. Thus:&prompt.user; key 92 hi52030 ) pasted from previous section
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
ADEN BED WOLF HAW HOT STUNAnd in the other window:s/key 92 hi52030 ) from previous section
Password:
(turning echo on)
Password:ADEN BED WOLF HAW HOT STUN
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
[etc.]This is the easiest mechanism if you have
a trusted machine. There is a Java S/Key key applet, The Java OTP
Calculator, that you can download and run locally on any
Java supporting brower.Generating multiple one-time passwordsSometimes we have to go places where no trusted machines or
connections are available. In this case, it is possible to use
the key command to generate a
number of one-time passwords in the same command; these can then
be printed out. For example:&prompt.user; key -n 25 57 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
33: WALT THY MALI DARN NIT HEAD
34: ASK RICE BEAU GINA DOUR STAG
…
56: AMOS BOWL LUG FAT CAIN INCH
57: GROW HAYS TUN DISH CAR BALMThe requests twenty-five keys in
sequence; the indicates the
ending iteration number; and the rest is as
before. Note that these are printed out in
reverse order of eventual use. If you are
really paranoid, you might want to write the results down by hand;
otherwise you can cut-and-paste into lpr. Note that each line shows both the
iteration count and the one-time password; you may still find it
handy to scratch off passwords as you use them.Restricting use of UNIX passwordsThe configuration file /etc/skey.access
can be used to configure restrictions on the use of UNIX passwords
based on the host name, user name, terminal port, or IP address of
a login session. The complete format of the file is documented in
the skey.access5 manual page; there are
also some security cautions there which should be read before
depending on this file for security.If there is no /etc/skey.access file
(which is the default state as FreeBSD is shipped), then all users
will be allowed to use UNIX passwords. If the file exists,
however, then all users will be required to use S/Key unless
explicitly permitted to do otherwise by configuration statements
in the skey.access file. In all cases, UNIX
passwords are permitted on the console.Here is a sample configuration file which illustrates the
three most common sorts of configuration statements:
permit internet 18.26.0.0 255.255.0.0
permit user jrl
permit port ttyd0The first line (permit
internet) allows users whose IP source address
(which is vulnerable to spoofing) matches the specified value and
mask, to use UNIX passwords. This should not be considered a
security mechanism, but rather, a means to remind authorized users
that they are using an insecure network and need to use S/Key for
authentication.The second line (permit user)
allows the specified user to use UNIX passwords at any time.
Generally speaking, this should only be used for people who are
either unable to use the key
program, like those with dumb terminals, or those who are
uneducable.The third line (permit port)
allows all users logging in on the specified terminal line to use
UNIX passwords; this would be used for dial-ups.KerberosContributed by &a.markm; (based on contribution by
&a.md;).Kerberos is a network add-on system/protocol that allows users
to authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and
more controllable.The following instructions can be used as a guide on how to set
up Kerberos as distributed for FreeBSD. However, you should refer to
the relevant manual pages for a complete description.In FreeBSD, the Kerberos is not that from the original
4.4BSD-Lite, distribution, but eBones, which had been previously
ported to FreeBSD 1.1.5.1, and was sourced from outside the
USA/Canada, and is thus available to system owners outside those
countries.For those needing to get a legal foreign distribution of this
software, please do not get it from a USA or
Canada site. You will get that site in big
trouble! A legal copy of this is available from
ftp.internat.freebsd.org, which is in
South Africa and an official FreeBSD mirror site.Creating the initial databaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should
change to the directory /etc/kerberosIV and
check that only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as
principal.* or master_key)
exist, then use the kdb_destroy command to
destroy the old Kerberos database, of if Kerberos is not running,
simply delete the extra files.You should now edit the krb.conf and
krb.realms files to define your Kerberos
realm. In this case the realm will be
GRONDAR.ZA and the server is
grunt.grondar.za. We edit or create the
krb.conf file:&prompt.root; cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They
are here as an example of how a machine may be made aware of
multiple realms. You may wish to not include them for
simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line
is a realm, and the second is a host in that realm that is acting
as a “key distribution centre”. The words admin server
following a hosts name means that host also provides an
administrative database server. For further explanation of these
terms, please consult the Kerberos man pages.Now we have to add grunt.grondar.za to
the GRONDAR.ZA realm and also add an entry to
put all hosts in the .grondar.za domain in
the GRONDAR.ZA realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here
as an example of how a machine may be made aware of multiple
realms. You may wish to remove them to simplify things.The first line puts the specific
system into the named realm. The rest of the lines show how to
default systems of a particular subdomain to a named realm.Now we are ready to create the database. This only needs to
run on the Kerberos server (or Key Distribution Centre). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:GRONDAR.ZA
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local
machine can pick it up. Use the kstash command to do this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making it all runTwo principals need to be added to the database for each system that will be secured with
Kerberos. Their names are kpasswd
and rcmd These two principals are
made for each system, with the instance being the name of the
individual system.These daemons, kpasswd and
rcmd allow other systems to change
Kerberos passwords and run commands like rcp, rlogin
and rsh.Now let's add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the server fileWe now have to extract all the instances which define the
services on each machine. For this we use the
ext_srvtab command. This will create a file which
must be copied or moved by secure
means to each Kerberos client's /etc/kerberosIV
directory. This file must be present on each server and client,
and is crucial to the operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must
be renamed to srvtab so that all the
server can pick it up. Use the mv
command to move it into place on the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not
deemed safe, then copy the client-new-srvtab to removable media
and transport it by secure physical means. Be sure to rename it to
srvtab in the client's
/etc/kerberosIV directory, and make sure it
is mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the databaseWe now have to add some user entries into the database. First
let's create an entry for the user jane. Use
the kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting it all outFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then
this will happen automatically when you reboot. This is only
necessary on the Kerberos server. Kerberos clients will
automagically get what they need from the
/etc/kerberosIV directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit
command to get a ticket for the id jane that we created above:&prompt.user; kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZANow try changing the password using passwd to check if the kpasswd daemon can
get authorization to the Kerberos database:&prompt.user; passwd
realm GRONDAR.ZA
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su privilegesKerberos allows us to give each
user who needs root privileges their own separatesupassword. We could now add an id which is
authorized to su to root. This is controlled by having an
instance of root associated with a
principal. Using kdb_edit we can create the
entry jane.root in the Kerberos
database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's
.klogin file:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZANow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZAUsing other commandsIn an earlier example, we created a principal called
jane with an instance root. This was based on a user with the same
name as the principal, and this is a Kerberos default; that a
<principal>.<instance> of the
form <username>.root will allow that
<username> to su to root if the necessary entries are in
the .klogin file in root's home directory:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZALikewise, if a user has in their own home directory lines of
the form:&prompt.user; cat ~/.klogin
jane@GRONDAR.ZA
jack@GRONDAR.ZAThis allows anyone in the GRONDAR.ZA
realm who has authenticated themselves to
jane or jack (via
kinit, see above) access to
rlogin to
jane's account or files on this system
(grunt) via rlogin, rsh or
rcp.For example, Jane now logs into another system, using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.grondar.za)
Password:
%prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine (Jane
having set up the .klogin file as above, and
the person in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.grondar.za)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995FirewallsContributed by &a.gpalmer; and
&a.alex;.Firewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on
private networks to provide enhanced security. This section will
hopefully explain what firewalls are, how to use them, and how to
use the facilities provided in the FreeBSD kernel to implement
them.People often think that having a firewall between your
companies internal network and the “Big Bad Internet”
will solve all your security problems.It may help, but a poorly setup firewall system is more of a
security risk than not having one at all. A firewall can only add
another layer of security to your systems, but they will not be
able to stop a really determined cracker from penetrating your
internal network. If you let internal security lapse because you
believe your firewall to be impenetrable, you have just made the
crackers job that bit easier.What is a firewall?There are currently two distinct types of firewalls in common
use on the Internet today. The first type is more properly called
a packet filtering router, where the
kernel on a multi-homed machine chooses whether to forward or
block packets based on a set of rules. The second type, known as
proxy servers, rely on daemons to
provide authentication and to forward packets, possibly on a
multi-homed machine which has kernel packet forwarding
disabled.Sometimes sites combine the two types of firewalls, so that
only a certain machine (known as a bastion
host) is allowed to send packets through a packet
filtering router onto an internal network. Proxy services are run
on the bastion host, which are generally more secure than normal
authentication mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this section
will concentrate on. Proxy servers can be built on FreeBSD from
third party software, but there is such a variety of proxy servers
available that it would be impossible to cover them in this
document.Packet filtering routersA router is a machine which forwards packets between two or
more networks. A packet filtering router has an extra piece of
code in its kernel, which compares each packet to a list of
rules before deciding if it should be forwarded or not. Most
modern IP routing software has packet filtering code in it,
which defaults to forwarding all packets. To enable the filters,
you need to define a set of rules for the filtering code, so
that it can decide if the packet should be allowed to pass or
not.To decide if a packet should be passed on or not, the code
looks through its set of rules for a rule which matches the
contents of this packets headers. Once a match is found, the
rule action is obeyed. The rule action could be to drop the
packet, to forward the packet, or even to send an ICMP message
back to the originator. Only the first match counts, as the
rules are searched in order. Hence, the list of rules can be
referred to as a “rule chain”.The packet matching criteria varies depending on the
software used, but typically you can specify rules which depend
on the source IP address of the packet, the destination IP
address, the source port number, the destination port number
(for protocols which support ports), or even the packet type
(UDP, TCP, ICMP, etc).Proxy serversProxy servers are machines which have had the normal system
daemons (telnetd, ftpd, etc) replaced with special servers.
These servers are called proxy
servers as they normally only allow onward
connections to be made. This enables you to run (for example) a
proxy telnet server on your firewall host, and people can telnet
in to your firewall from the outside, go through some
authentication mechanism, and then gain access to the internal
network (alternatively, proxy servers can be used for signals
coming from the internal network and heading out).Proxy servers are normally more secure than normal servers,
and often have a wider variety of authentication mechanisms
available, including “one-shot” password systems so that even
if someone manages to discover what password you used, they will
not be able to use it to gain access to your systems as the
password instantly expires. As they do not actually give users
access to the host machine, it becomes a lot more difficult for
someone to install backdoors around your security system.Proxy servers often have ways of restricting access further,
so that only certain hosts can gain access to the servers, and
often they can be set up so that you can limit which users can
talk to which destination machine. Again, what facilities are
available depends largely on what proxy software you
choose.What does IPFW allow me to do?IPFW, the software supplied with FreeBSD,
is a packet filtering and accounting system which resides in the
kernel, and has a user-land control utility,
ipfw8. Together, they allow you to define and
query the rules currently used by the kernel in its routing
decisions.There are two related parts to IPFW. The
firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of
your router, based on similar rules to the firewall section. This
allows you to see (for example) how much traffic your router is
getting from a certain machine, or how much WWW (World Wide Web)
traffic it is forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDAs the main part of the IPFW system lives
in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want,
and recompile your kernel. See
reconfiguring the kernel for
more details on how to recompile your kernel.There are currently three kernel configuration options
relevant to IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
syslogd8. Without this option, even
if you specify that packets should be logged in the filter
rules, nothing will happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
syslogd8 on a per entry basis. You
may wish to use this option in hostile environments in
which you want to log firewall activity, but do not want
to be open to a denial of service attack via syslog
flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To
resume logging, you will need to reset the associated
counter using the ipfw8
utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWThe configuration of the IPFW software is
done through the ipfw8 utility. The syntax
for this command looks quite complicated, but it is relatively
simple once you understand its structure.There are currently four different command categories used by
the utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how
packets are accepted, rejected, and logged. Listing is used to
examine the contents of your rule set (otherwise known as the
chain) and packet counters (accounting). Flushing is used to
remove all entries from the chain. Clearing is used to zero out
one or more accounting entries.Altering the IPFW rulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in
output.The command given can be shortened to
the shortest unique form. The valid
commands are:addAdd an entry to the firewall/accounting rule
listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used separate
firewall and accounting entries. The present version provides
packet accounting with each firewall entry.If an index value is supplied,
it used to place the entry at a specific point in the chain.
Otherwise, the entry is placed at the end of the chain at an
index 100 greater than the last chain entry (this does not
include the default policy, rule 65535, deny).The log option causes matching
rules to be output to the system console if the kernel was
compiled with IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port
unreachable (as appropriate) packet to the
source.allowPass the packet on as normal. (aliases:
pass and accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the
packet based on this rule. The search continues with
the next chain entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/markportvia interfaceYou can only specify port in
conjunction with protocols which support
ports (UDP and TCP).The is optional and may
specify the IP address or domain name of a local IP interface,
or an interface name (e.g. ed0) to
match only packets coming through this interface. Interface unit
numbers can be specified with an optional wildcard. For example,
ppp* would match all kernel PPP
interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP
address. is a decimal
number representing how many bits in the address mask should be
set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any
address in a class C subnet (in this case, 192.216.222) to be
matched. is an IP
address which will be logically AND'ed with the address given.
The keyword any may be used to
specify “any IP address”.The port numbers to be blocked are specified as:
port,port,port…to specify either a single port or a list of
ports, or
port-port to specify a range of ports. You may also
combine a single range with a list, but the range must always be
specified first.The options available are:fragMatches if the packet is not the first fragment of
the datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma
separated list of options specified in
spec. The supported list of IP
options are: ssrr (strict
source route), lsrr (loose
source route), rr (record
packet route), and ts
(timestamp). The absence of a particular option may be
denoted with a leading !.establishedMatches if the packet is part of an already
established TCP connection (i.e. it has the RST or ACK
bits set). You can optimize the performance of the
firewall by placing established
rules early in the chain.setupMatches if the packet is an attempt to establish a
TCP connection (the SYN bit set is set but the ACK bit
is not).tcpflags flagsMatches if the TCP header contains the comma
separated list of flags. The
supported flags are fin,
syn, rst,
psh, ack, and
urg. The absence of a particular
flag may be indicated by a leading !.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types
separated by commas. Commonly used ICMP types are:
0 echo reply (ping reply),
+ 3 destination unreachable,
5 redirect, 8 echo request (ping request), and
11 time exceeded (used to
indicate TTL expiration as with
traceroute8).Listing the IPFW rulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is
the only way to see accounting counters.-tDisplay the last match times for each chain entry.
The time listing is incompatible with the input syntax
used by the ipfw8 utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW rulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny
policy will leave your system cut off from the network until
allow entries are added to the chain.Clearing the IPFW packet countersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example commands for ipfwThis command will deny all packets from the host
evil.crackers.org to the telnet port of the
host nice.people.org by being forwarded by
the router:&prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the
entire crackers.org network (a class C) to the
nice.people.org machine (any port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry
was matched with:&prompt.root; ipfw -at lBuilding a packet filtering firewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and I cannot tell
you how to build a firewall to meet your particular
requirements.When initially setting up your firewall, unless you have a
test bench setup where you can configure your firewall host in a
controlled environment, I strongly recommend you use the logging
version of the commands and enable logging in the kernel. This
will allow you to quickly identify problem areas and cure them
without too much disruption. Even after the initial setup phase is
complete, I recommend using the logging for of `deny' as it allows
tracing of possible attacks and also modification of the firewall
rules if your requirements alter.If you use the logging versions of the accept command, it can generate
large amounts of log data as one log line
will be generated for every packet that passes through the
firewall, so large ftp/http transfers, etc, will really slow the
system down. It also increases the latencies on those packets as
it requires more work to be done by the kernel before the packet
can be passed on. syslogd with also start using up a lot more
processor time as it logs all the extra data to disk, and it
could quite easily fill the partition
/var/log is located on.As currently supplied, FreeBSD does not have the ability to
load firewall rules at boot time. My suggestion is to put a call
to a shell script in the /etc/netstart
script. Put the call early enough in the netstart file so that the
firewall is configured before any of the IP interfaces are
configured. This means that there is no window during which time
your network is open.The actual script used to load the rules is entirely up to
you. There is currently no support in the ipfw utility for loading multiple rules in
the one command. The system I use is to use the command:&prompt.root; ipfw listto write a list of the current rules out to a file, and then
use a text editor to prepend ipfw
before all the lines. This will allow the script to
be fed into /bin/sh and reload the rules into the kernel. Perhaps
not the most efficient way, but it works.The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much
access to the outside world you want to allow from the inside.
Some general rules are:Block all incoming access to ports below 1024 for TCP.
This is where most of the security sensitive services are,
like finger, SMTP (mail) and telnet.Block all incoming UDP
traffic. There are very few useful services that travel over
UDP, and what useful traffic there is is normally a security
threat (e.g. Suns RPC and NFS protocols). This has its
disadvantages also, since UDP is a connectionless protocol,
denying incoming UDP traffic also blocks the replies to
outgoing UDP traffic. This can cause a problem for people
(on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
packets coming from ports 191 and 1525 to any internal UDP
port through the firewall. ntp is another service you may
consider allowing through, which comes from port 123.Block traffic to port 6000 from the outside. Port 6000
is the port used for access to X11 servers, and can be a
security threat (especially if people are in the habit of
doing xhost + on their
workstations). X11 can actually use a range of ports
starting at 6000, the upper limit being how many X displays
you can run on the machine. The upper limit as defined by
RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL
servers, etc). It is probably a good idea to block those as
well, as they normally fall outside the 1-1024 range
specified above.Another checklist for firewall configuration is available from
CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filteringAs I said above, these are only
guidelines. You will have to decide what
filter rules you want to use on your firewall yourself. I cannot
accept ANY responsibility if someone breaks into your network,
even if you follow the advice given above.
diff --git a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
index b34fa0411c..85ff0bc7b4 100644
--- a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
@@ -1,794 +1,838 @@
FreeBSD Project StaffThe FreeBSD Project is managed and operated by the following
groups of people:The FreeBSD Core TeamThe FreeBSD core team constitutes the project's “Board of
Directors”, responsible for deciding the project's overall goals
and direction as well as managing specific
areas of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.bde;&a.gibbs;&a.dg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.guido;&a.sos;&a.peter;&a.wollman;&a.joerg;The FreeBSD DevelopersThese are the people who have commit privileges and do the
engineering work on the FreeBSD source tree. All core team members
are also developers.&a.ugen;&a.mbarkah;&a.stb;&a.pb;&a.abial;&a.jb;&a.torstenb;&a.dburr;&a.charnier;&a.luoqi;&a.ejc;&a.kjc;&a.gclarkii;&a.archie&a.cracauer;&a.adam;&a.dillon;&a.dufault;&a.uhclem;&a.tegge;&a.eivind;&a.julian;&a.rse;&a.se;&a.sef;&a.fenner;&a.jfieber;&a.jfitz;&a.scrappy;&a.lars;
+
+ &.dirk;
+
+
&a.billf;
-
+
+
+ &a.gallatin;
+
+
&a.tg;&a.brandon;&a.graichen;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.thepish;&a.jhay;&a.helbig;&a.ghelmer;&a.erich;&a.nhibma;&a.flathill;
-
+
+
+ &a.foxfair;
+
+
&a.hosokawa;&a.hsu;&a.mph;&a.itojun;&a.mjacob;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.motoyuki;&a.jkoshy;&a.kuriyama;&a.grog;&a.jlemon;&a.truckman;&a.imp;&a.smace;&a.mckay;&a.mckusick;&a.ken;
-
+
+
+ &a.hm;
+
+
&a.tedm;&a.amurai;&a.markm;&a.max;&a.alex;
+
+ &a.newton;
+
+
&a.rnordier;&a.davidn;&a.obrien;&a.danny;&a.ljo;&a.fsmp;&a.smpatel;&a.wpaul;&a.jmacd;&a.wes;&a.steve;&a.mpp;&a.dfr;&a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.dima;&a.sada;&a.wosch;&a.ats;&a.jseger;
-
+
+
+ &a.simokawa;
+
+
&a.vanilla;&a.msmith;&a.des;&a.brian;
-
+
+
+ &a.mks;
+
+
&a.stark;&a.karl;&a.dt;&a.cwt;&a.pst;&a.hoek;&a.nectar;&a.swallace;&a.dwhite;&a.nate;&a.yokota;&a.jmz;&a.archie;The FreeBSD Documentation ProjectThe FreeBSD
Documentation Project is responsible for a number of
different services, each service being run by an individual and his
deputies (if any):Documentation Project Manager&a.nik;Webmaster&a.wosch;Handbook & FAQ Editor&a.faq;News Editor&a.nsj;Deputy: &a.john;FreeBSD Really-Quick NewsLetter EditorChris Coleman chrisc@vmunix.com
- Gallery and Commercial Editor
+ Gallery Editor&a.nsj;Deputy: &a.cawimm;
-
+
+
+ Commercial Editor
+
+
+ &a.mbarkah;
+
+
+
+
+ Web Changes Editor
+
+
+ &a.mbarkah;
+
+
+
Style Police & Art Director&a.opsys;Database Engineer&a.mayo;CGI Engineer&a.stb;Bottle Washing&a.nsj;LinuxDoc to DocBook conversion&a.nik;Who Is Responsible for WhatPrincipal Architect&a.dg;Documentation Project Manager&a.nik;Internationalization&a.ache;Networking&a.wollman;Postmaster&a.jmb;Release Coordinator&a.jkh;Public Relations & Corporate
Liaison&a.jkh;Security Officer&a.guido;>Source Repository ManagersPrincipal: &a.peter;Assistant: &a.jdp;International (Crypto): &a.markm;Ports Manager&a.asami;XFree86 Project, Inc. Liaison&a.rich;Usenet Support&a.joerg;GNATS Administrator&a.steve;Webmaster&a.wosch;
diff --git a/en_US.ISO8859-1/books/porters-handbook/book.sgml b/en_US.ISO8859-1/books/porters-handbook/book.sgml
index 092d021ad9..59c780838e 100644
--- a/en_US.ISO8859-1/books/porters-handbook/book.sgml
+++ b/en_US.ISO8859-1/books/porters-handbook/book.sgml
@@ -1,4523 +1,4673 @@
Installing Applications: The Ports collectionContributed by &a.jraynard;.The FreeBSD Ports collection allows you to compile and install a
very wide range of applications with a minimum of effort.For all the hype about open standards, getting a program to work
on different versions of Unix in the real world can be a tedious and
tricky business, as anyone who has tried it will know. You may be
lucky enough to find that the program you want will compile cleanly on
your system, install itself in all the right places and run flawlessly
“out of the box”, but this is unfortunately rather rare. With most
programs, you will find yourself doing a fair bit of head-scratching,
and there are quite a few programs that will result in premature
greying, or even chronic alopecia...Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but
they have an unfortunate tendency to triumphantly announce that your
system is something you have never heard of and then ask you lots of
questions that sound like a final exam in system-level Unix
programming (Does your system's gethitlist function return a const
pointer to a fromboz or a pointer to a const fromboz? Do you have
Foonix style unacceptable exception handling? And if not, why
not?).Fortunately, with the Ports collection, all the hard work
involved has already been done, and you can just type make install
and get a working program.Why Have a Ports Collection?The base FreeBSD system comes with a very wide range of tools
and system utilities, but a lot of popular programs are not in the
base system, for good reasons:-Programs that some people cannot live without and other
people cannot stand, such as a certain Lisp-based editor.Programs which are too specialised to put in the base
system (CAD, databases).Programs which fall into the “I must have a look at that
when I get a spare minute” category, rather than
system-critical ones (some languages, perhaps).Programs that are far too much fun to be supplied with a
serious operating system like FreeBSD ;-)However many programs you put in the base system, people
will always want more, and a line has to be drawn somewhere
(otherwise FreeBSD distributions would become absolutely
enormous).Obviously it would be unreasonable to expect everyone to port
their favourite programs by hand (not to mention a tremendous amount
of duplicated work), so the FreeBSD Project came up with an
ingenious way of using standard tools that would automate the
process.Incidentally, this is an excellent illustration of how “the
Unix way” works in practice by combining a set of simple but very
flexible tools into something very powerful.How Does the Ports Collection Work?Programs are typically distributed on the Internet as a
tarball consisting of a
Makefile and the source code for the program and usually some
instructions (which are unfortunately not always as instructive as
they could be), with perhaps a configuration script.The standard scenario is that you FTP down the tarball, extract
it somewhere, glance through the instructions, make any changes
that seem necessary, run the configure script to set things up and
use the standard make program to compile and install the program
from the source.FreeBSD ports still use the tarball mechanism, but use a
skeleton to hold the
"knowledge" of how to get the program working on FreeBSD,
rather than expecting the user to be able to work it out. They also
supply their own customised
Makefile, so that almost
every port can be built in the same way.If you look at a port skeleton (either on your FreeBSD
system or the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about Getting a port).“How on earth can this do anything?” I hear you cry. “There
is no source code there!”Fear not, gentle reader, all will become clear (hopefully).
Let's see what happens if we try and install a port. I have chosen
ElectricFence, a useful tool for developers, as the skeleton is
more straightforward than most.If you are trying this at home, you
will need to be root.&prompt.root; cd /usr/ports/devel/ElectricFence
&prompt.root; make install
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
===> Extracting for ElectricFence-2.0.5
===> Patching for ElectricFence-2.0.5
===> Applying FreeBSD patches for ElectricFence-2.0.5
===> Configuring for ElectricFence-2.0.5
===> Building for ElectricFence-2.0.5
[lots of compiler output...]
===> Installing for ElectricFence-2.0.5
===> Warning: your umask is "0002". If this is not desired, set it to
an appropriate value and install this port again by ``make reinstall''.
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
===> Compressing manual pages for ElectricFence-2.0.5
===> Registering installation for ElectricFence-2.0.5To avoid confusing the issue, I have completely removed the
build output.If you tried this yourself, you may well have got something like
this at the start:-&prompt.root; make install
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.The make program has noticed that you did not have a local
copy of the source code and tried to FTP it down so it could get the
job done. I already had the source handy in my example, so it did
not need to fetch it.Let's go through this and see what the make program was
doing.Locate the source code tarball. If it is not available locally, try to
grab it from an FTP site.Run a checksum
test on the tarball to make sure it has not been tampered
with, accidentally truncated, downloaded in ASCII mode, struck
by neutrinos while in transit, etc.Extract the tarball into a temporary work directory.Apply any patches
needed to get the source to compile and run under FreeBSD.Run any configuration script required by the build
process and correctly answer any questions it asks.(Finally!) Compile the code.Install the program executable and other supporting
files, man pages, etc. under the
/usr/local hierarchy, where they will not
get mixed up with system programs. This also makes sure that
all the ports you install will go in the same place, instead
of being flung all over your system.Register the installation in a database. This means that,
if you do not like the program, you can cleanly remove all traces of it from
your system.Scroll up to the make output and see if you can match these
steps to it. And if you were not impressed before, you should be by
now!Getting a FreeBSD PortThere are two ways of getting hold of the FreeBSD port for a
program. One requires a FreeBSD
CDROM, the other involves using an Internet Connection.Compiling ports from CDROMAssuming that your FreeBSD CDROM is in the drive and mounted on
/cdrom (and the mount point
must be /cdrom), you should
then be able to build ports just as you normally do and the port
collection's built in search path should find the tarballs in
/cdrom/ports/distfiles/ (if they exist there)
rather than downloading them over the net.
-
+
+ Another way of doing this, if you want to just use the port
+ skeletons on the CDROM, is to set these variables in
+ /etc/make.conf:
+
+
+PORTSDIR= /cdrom/ports
+DISTDIR= /tmp/distfiles
+WRKDIRPREFIX= /tmp
+
+ Substitute /tmp for any place you have enough
+ free space. Then, just cd to the appropriate
+ subdirectory under /cdrom/ports and type
+ make install as
+ usual. WRKDIRPREFIX will cause the port to be
+ build under /tmp/cdrom/ports; for instance,
+ games/oneko will be built under
+ /tmp/cdrom/ports/games/oneko.
+
There are some ports for which we cannot provide the
original source in the CDROM due to licensing limitations. In
that case, you will need to look at the section on Compiling ports using an Internet connection.Compiling ports from the InternetIf you do not have a CDROM, or you want to make sure you get
the very latest version of the port you want, you will need to
download the
skeleton for the port. Now
this might sound like rather a fiddly job full of pitfalls, but
it is actually very easy.First, if you are running a release version of FreeBSD, make
sure you get the appropriate “upgradekiet” for your
replease from the ports
web page. These packages include files that have been
updated since the release that you may need to compile new
ports.The key to the skeletons is that the FreeBSD FTP server can create
on-the-fly
tarballs for you. Here is
how it works, with the gnats program in the databases directory as
an example (the bits in square brackets are comments. Do not type
them in if you are trying this yourself!):-&prompt.root; cd /usr/ports
&prompt.root; mkdir databases
&prompt.root; cd databases
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports/databases
+>cd /pub/FreeBSD/ports/ports/databases>get gnats.tar
[tars up the gnats skeleton for us]
>quit
&prompt.root; tar xf gnats.tar
[extract the gnats skeleton]
&prompt.root; cd gnats
&prompt.root; make install
[build and install gnats]What happened here? We connected to the FTP server in the
usual way and went to its databases sub-directory. When we gave it
the command get gnats.tar, the FTP server tarred up the gnats directory for us.We then extracted the gnats skeleton and went into the gnats
directory to build the port. As we explained earlier, the make process noticed we did not have a
copy of the source locally, so it fetched one before extracting,
patching and building it.Let's try something more ambitious now. Instead of getting a
single port skeleton, let's get a whole sub-directory, for example
all the database skeletons in the ports collection. It looks
almost the same:-&prompt.root; cd /usr/ports
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports
+>cd /pub/FreeBSD/ports/ports>get databases.tar
[tars up the databases directory for us]
>quit
&prompt.root; tar xf databases.tar
[extract all the database skeletons]
&prompt.root; cd databases
&prompt.root; make install
[build and install all the database ports]With half a dozen straightforward commands, we have now got a
set of database programs on our FreeBSD machine! All we did that
was different from getting a single port skeleton and building it
was that we got a whole directory at once, and compiled everything
in it at once. Pretty impressive, no?If you expect to be installing many ports, it is probably
worth downloading all the ports directories.SkeletonsA team of compulsive hackers who have forgotten to eat in a
frantic attempt to make a deadline? Something unpleasant lurking in
the FreeBSD attic? No, a skeleton here is a minimal framework that
supplies everything needed to make the ports magic work.MakefileThe most important component of a skeleton is the Makefile.
This contains various statements that specify how the port should
be compiled and installed. Here is the Makefile for
ElectricFence:-
# New ports collection makefile for: Electric Fence
# Version required: 2.0.5
# Date created: 13 November 1997
# Whom: jraynard
#
# $Id$
#
DISTNAME= ElectricFence-2.0.5
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SUNSITE}
MASTER_SITE_SUBDIR= devel/lang/c
MAINTAINER= jraynard@freebsd.org
MAN3= libefence.3
do-install:
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
.include <bsd.port.mk>The lines beginning with a "#" sign are comments for
the benefit of human readers (as in most Unix script
files).DISTNAME specifies the name of the tarball, but without the
extension.CATEGORIES states what kind of program this is. In
this case, a utility for developers. See the categories section of this
handbook for a complete list.MASTER_SITES is the URL(s) of the master FTP site,
which is used to retrieve the tarball if it is not available on the local system.
This is a site which is regarded as reputable, and is normally the
one from which the program is officially distributed (in so far
as any software is "officially" distributed on the
Internet).MAINTAINER is the email address of the person who is
responsible for updating the skeleton if, for example a new
version of the program comes out.Skipping over the next few lines for a minute, the line
.include <bsd.port.mk> says
that the other statements and commands needed for this port are
in a standard file called bsd.port.mk. As
these are the same for all ports, there is no point in duplicating
them all over the place, so they are kept in a single standard
file.This is probably not the place to go into a detailed
examination of how Makefiles work; suffice it to say that the line
starting with MAN3 ensures that the ElectricFence man page is
compressed after installation, to help conserve your precious disk
space. The original port did not provide an install target,
so the three lines from do-install ensure that the files
produced by this port are placed in the correct
destination.The files directoryThe file containing the checksum for the port is called
md5, after the MD5 algorithm used for ports
checksums. It lives in a directory with the slightly confusing
name of files.This directory can also contain other miscellaneous files that
are required by the port and do not belong anywhere else.The patches directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The pkg directoryThis program contains three quite useful files:-COMMENT — a one-line description of
the program.DESCR — a more detailed description.PLIST — a list of all the files
that will be created when the program is installed.What to do when a port does not work.Oh. You can do one of four (4) things :Fix it yourself. Technical details on how ports work can
be found in
Porting applications.Gripe. This is done by e-mail only! Send such e-mail to
the &a.ports; and please include the name/version of the port,
where you got both the port source & distfile(s) from, and
what the text of the error was.Forget it. This is the easiest for most — very few of the
programs in ports can be classified as essential!Grab the pre-compiled package from a ftp server. The
“master” package collection is on FreeBSD's FTP server in
the packages
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/">packages
directory, though check your local mirror first,
please! These are more likely to work (on the whole) than
trying to compile from source and a lot faster besides! Use
the pkg_add1 program to install a
package file on your system.Some Questions and AnswersQ. I thought this was going to be a discussion about
modems??!A. Ah. You must be thinking of the serial ports on the
back of your computer. We are using “port” here to mean the
result of “porting” a program from one version of Unix to
another. (It is an unfortunate bad habit of computer people to
use the same word to refer to several completely different
things).Q. I thought you were supposed to use packages to install
extra programs?A. Yes, that is usually the quickest and easiest way of
doing it.Q. So why bother with ports then?A. Several reasons:-The licensing conditions on some software
distributions require that they be distributed as source
code, not binaries.Some people do not trust binary distributions. At
least with source code you can (in theory) read through
it and look for potential problems yourself.If you have some local patches, you will need the
source to add them yourself.You might have opinions on how a program should be
compiled that differ from the person who did the package
— some people have strong views on what optimisation
setting should be used, whether to build debug versions
and then strip them or not, etc. etc.Some people like having code around, so they can
read it if they get bored, hack around with it, borrow
from it (licence terms permitting, of course!) and so
on.If you ain't got the source, it ain't software!
;-) Q. What is a patch?A. A patch is a small (usually) file that specifies how to
go from one version of a file to another. It contains text
that says, in effect, things like “delete line 23”, “add
these two lines after line 468” or “change line 197 to
this”. Also known as a “diff”, since it is generated by a
program of that name. Q. What is all this about
tarballs?A. It is a file ending in .tar or
.tar.gz (with variations like
.tar.Z, or even .tgz
if you are trying to squeeze the names into a DOS
filesystem).Basically, it is a directory tree that has been archived
into a single file (.tar) and optionally
compressed (.gz). This technique was
originally used for Tape
ARchives (hence the name tar), but it is
a widely used way of distributing program source code around
the Internet.You can see what files are in them, or even extract them
yourself, by using the standard Unix tar program, which comes
with the base FreeBSD system, like this:-&prompt.user; tar tvzf foobar.tar.gz
&prompt.user; tar xzvf foobar.tar.gz
&prompt.user; tar tvf foobar.tar
&prompt.user; tar xvf foobar.tar Q. And a checksum?A. It is a number generated by adding up all the data in
the file you want to check. If any of the characters change,
the checksum will no longer be equal to the total, so a simple
comparison will allow you to spot the difference. (In
practice, it is done in a more complicated way to spot
problems like position-swapping, which will not show up with a
simplistic addition).Q. I did what you said for compiling ports from a CDROM and it worked great
until I tried to install the kermit port:-&prompt.root; make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.Why can it not be found? Have I got a dud CDROM?A. The licensing terms for kermit do not allow us to put
the tarball for it on the CDROM, so you will have to fetch it
by hand — sorry! The reason why you got all those error
messages was because you were not connected to the Internet at
the time. Once you have downloaded it from any of the sites
above, you can re-start the process (try and choose the
nearest site to you, though, to save your time and the
Internet's bandwidth).Q. I did that, but when I tried to put it into
/usr/ports/distfiles I got some error
about not having permission.A. The ports mechanism looks for the tarball in
/usr/ports/distfiles, but you will not be
able to copy anything there because it is sym-linked to the
CDROM, which is read-only. You can tell it to look somewhere
else by doing&prompt.root; make DISTDIR=/where/you/put/it installQ. Does the ports scheme only work if you have everything
in /usr/ports? My system administrator
says I must put everything under
/u/people/guests/wurzburger, but it does
not seem to work.A. You can use the PORTSDIR and PREFIX variables to tell
the ports mechanism to use different directories. For
instance,&prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports installwill compile the port in
/u/people/guests/wurzburger/ports and
install everything under /usr/local.&prompt.root; make PREFIX=/u/people/guests/wurzburger/local installwill compile it in /usr/ports and
install it in
/u/people/guests/wurzburger/local.And of course&prompt.root; make PORTSDIR=.../ports PREFIX=.../local installwill combine the two (it is too long to fit on the page if
I write it in full, but I am sure you get the idea).If you do not fancy typing all that in every time you
install a port (and to be honest, who would?), it is a good
idea to put these variables into your environment.Q. I do not have a FreeBSD CDROM, but I would like to have
all the tarballs handy on my system so I do not have to wait
for a download every time I install a port. Is there an easy
way to get them all at once?A. To get every single tarball for the ports collection,
do&prompt.root; cd /usr/ports
&prompt.root; make fetchFor all the tarballs for a single ports directory,
do&prompt.root; cd /usr/ports/directory
&prompt.root; make fetchand for just one port — well, I think you have guessed
already.Q. I know it is probably faster to fetch the tarballs from
one of the FreeBSD mirror sites close by. Is there any way to
tell the port to fetch them from servers other than ones
listed in the MASTER_SITES?A. Yes. If you know, for example, ftp.FreeBSD.ORG is much
closer than sites listed in MASTER_SITES, do as following
example.&prompt.root; cd /usr/ports/directory
-&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
+&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetchQ. I want to know what files make is going to need before
it tries to pull them down.A. make fetch-list will display a list of the files
needed for a port.Q. Is there any way to stop the port from compiling? I
want to do some hacking on the source before I install it, but
it is a bit tiresome having to watch it and hit control-C
every time.A. Doing make extract will stop it after it has fetched
and extracted the source code.Q. I am trying to make my own port and I want to be able
to stop it compiling until I have had a chance to see if my
patches worked properly. Is there something like make
extract, but for patches?A. Yep, make patch is what you want. You will probably
find the PATCH_DEBUG option useful as well. And by the way,
thank you for your efforts!Q. I have heard that some compiler options can cause bugs.
Is this true? How can I make sure that I compile ports with
the right settings?A. Yes, with version 2.6.3 of gcc (the version shipped
with FreeBSD 2.1.0 and 2.1.5), the option could result in
buggy code unless you used the option as
well. (Most of the ports don't use ). You
should be able to specify the compiler
options used by something like&prompt.root; make CFLAGS='-O2 -fno-strength-reduce' installor by editing /etc/make.conf, but
unfortunately not all ports respect this. The surest way is to
do make configure, then go into the source directory and
inspect the Makefiles by hand, but this can get tedious if the
source has lots of sub-directories, each with their own
Makefiles.Q. There are so many ports it is hard to find the one I
want. Is there a list anywhere of what ports are available?A. Look in the INDEX file in
/usr/ports. If you would like to search the
ports collection for a keyword, you can do that too. For example,
you can find ports relevant to the LISP programming language
using:&prompt.user; cd /usr/ports
&prompt.user; make search key=lispQ. I went to install the foo port but the system
suddenly stopped compiling it and starting compiling the
bar
port. What's going on?A. The foo port needs something that is supplied with
bar — for instance, if foo uses graphics, bar might have
a library with useful graphics processing routines. Or bar
might be a tool that is needed to compile the foo
port. Q. I installed the grizzle
program from the ports and frankly it is a complete waste of
disk space. I want to delete it but I do not know where it put
all the files. Any clues?A. No problem, just do&prompt.root; pkg_delete grizzle-6.5
Q. Hang on a minute, you have to know the version number to
use that command. You do not seriously expect me to remember
that, do you??A. Not at all, you can find it out by doing&prompt.root; pkg_info -a | grep grizzle
Information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.Q. Talking of disk space, the ports directory seems to be
taking up an awful lot of room. Is it safe to go in there and
delete things?A. Yes, if you have installed the program and are fairly
certain you will not need the source again, there is no point
in keeping it hanging around. The best way to do this
is&prompt.root; cd /usr/ports
&prompt.root; make cleanwhich will go through all the ports subdirectories and
delete everything except the skeletons for each port.Q. I tried that and it still left all those tarballs or
whatever you called them in the distfiles
directory. Can I delete those as well?A. Yes, if you are sure you have finished with them, those
can go as well.Q. I like having lots and lots of programs to play with.
Is there any way of installing all the ports in one go?A. Just do&prompt.root; cd /usr/ports
&prompt.root; make installQ. OK, I tried that, but I thought it would take a very
long time so I went to bed and left it to get on with it. When
I looked at the computer this morning, it had only done three
and a half ports. Did something go wrong?A. No, the problem is that some of the ports need to ask
you questions that we cannot answer for you (eg “Do you want
to print on A4 or US letter sized paper?”) and they need to
have someone on hand to answer them.Q. I really do not want to spend all day staring at the
monitor. Any better ideas?A. OK, do this before you go to bed/work/the local
park:-&prompt.root cd /usr/ports
&prompt.root; make -DBATCH installThis will install every port that does
not require user input. Then, when you
come back, do&prompt.root; cd /usr/ports
&prompt.root; make -DIS_INTERACTIVE installto finish the job.Q. At work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do
what we need. Is there any way of making our own packages, so
we can distribute it more easily around our sites?A. No problem, assuming you know how to make patches for
your changes:-&prompt.root; cd /usr/ports/somewhere/frobble
&prompt.root; make extract
&prompt.root; cd work/frobble-2.8
[Apply your patches]
&prompt.root; cd ../..
&prompt.root; make packageQ. This ports stuff is really clever. I am desperate to
find out how you did it. What is the secret?A. Nothing secret about it at all, just look at the
bsd.ports.mk and
bsd.ports.subdir.mk files in your makefiles
directory.Readers with an aversion to intricate shell-scripts are
advised not to follow this link...)Making a port yourselfContributed by &a.jkh;, &a.gpalmer;, &a.asami;
&a.obrien; and &a.hoek;. 28 August 1996.So, now you are interested in making your own port?
Great!What follows are some guidelines for creating a new port for
FreeBSD. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Only a fraction of the overridable variables
(VAR) are mentioned
in this document. Most (if not all) are documented at the start of
bsd.port.mk. This file users a non-standard
tab setting. Emacs and
Vim should recognise the setting on
loading the file. vi or ex
can be set to use the correct value by typing :set
tabstop=4 once the file has been loaded.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into DISTDIR, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the MakefileThe minimal Makefile would
look something like this:
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# $Id$
#
DISTNAME= oneko-1.1b
CATEGORIES= games
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG
MAN1= oneko.1
MANCOMPRESSED= yes
USE_IMAKE= yes
.include <bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the sample Makefile
section.Writing the description filesThere are three description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.COMMENTThis is the one-line description of the port.
Please do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the screen.DESCRThis is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual or an
in-depth description on how to use or compile the port!
Please be careful if you are copying from the
README or manpage; too often
they are not a concise description of the port or are in an
awkward format (e.g., manpages have justified spacing). If the
ported software has an official WWW homepage, you should list
it here.It is recommended that you sign the name at the end of
this file, as in:
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
http://www.oneko.org/
- Satoshi
asami@cs.berkeley.eduPLISTThis file lists all the files installed by the port. It
is also called the “packing list” because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). If you are using the
MANn variables (as
you should be), do not list any manpages here.Here is a small example:
bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/onekoRefer to the pkg_create1 man page
for details on the packing list.You should list all the files, but not the name
directories, in the list. Also, if the port creates
directories for itself during installtion, make sure to add
@dirrm lines as necessary to remove them
when the port is deleted.It is recommended that you keep all the filenames in
this file sorted alphabetically. It will make verifying the
changes when you upgrade the port much easier.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. These are
the important points you need to verify.PLIST does not contain anything not
installed by your portPLIST contains everything that is
installed by your portYour port can be installed multiple times using the
reinstall targetYour port cleans
up after itself upon deinstallRecommended test orderingmake installmake packagemake deinstallpkg_add `make package-name`make deinstallmake reinstallmake packageMake sure that there aren't any warnings issued in any of
the package and
deinstall stages, After step 3, check
to see if all the new directories are correctly deleted. Also,
try using the software after step 4, to ensure that is works
correctly when installed from a package.Checking your port with portlintPlease use portlint to see if your port
conforms to our guidelines. The portlint
program is part of the ports collection. In particular, your may
want to check if the Makefile is in the right
shape and the package is
named appropriately.Submitting the portFirst, make sure you have read the Do's and Dont's section.Now that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. We do not need your
work directory or the
pkgname.tgz package, so delete them
now. Next, simply include the output of shar `find
port_dir` in a bug report and send it with the
send-pr1 program (see Bug
Reports and General Commentary for more information
about send-pr1. If the uncompressed port is larger than
20KB, you should compress it into a tarfile and use uuencode1 before including it in the bug report (uuencoded
tarfiles are acceptable even if the bug report is smaller than
20KB but are not preferred). Be sure to classify the bug report as
category ports and class
change-request. (Do not mark the report
confidential!)One more time, do not include the original source
distfile, the work directory, or the
package you built with make
package.In the past, we asked you to upload new port submissions
in our ftp site (ftp.freebsd.org). This is no longer
recommended as read access is turned off on that
incoming/ directory of that site due to
the large amount of pirated software showing up there.We will look at your port,
get back to you if necessary, and put it in the
tree. Your name will also appear in the list of “Additional
FreeBSD contributors” on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in DISTDIR.
If fetch cannot find the required files in DISTDIR it will look up the
URL MASTER_SITES,
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
The extract target is run. It looks for your port's
distribution file (typically a gzip'd tarball) in DISTDIR and unpacks it into a temporary subdirectory
specified by WRKDIR
(defaults to work).The patch target is run. First, any patches defined
in PATCHFILES are
applied. Second, if any patches are found in PATCHDIR (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.The configure target is run. This can do any one of
many different things.If it exists,
scripts/configure is run.If HAS_CONFIGURE or
GNU_CONFIGURE
is set,
WRKSRC/configure is
run.If USE_IMAKE is set,
XMKMF
(default: xmkmf
-a) is run.The build target is run. This is responsible for
- descending into the ports' private working directory
+ descending into the port's private working directory
(WRKSRC) and
building it. If USE_GMAKE is set, GNU
make will be used,
otherwise the system make
will be used.The above are the default actions. In addition, you can
define targets pre-something or post-something, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-something. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-something target in
your Makefile.The “main” targets (e.g., extract, configure, etc.) do nothing more than
- make sure all the stages up to that one is completed and
+ make sure all the stages up to that one are completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (foo.tar.gz or
foo.tar.Z) and copy it into
DISTDIR. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, you might want to put a copy on a
reliable ftp or http server that you control (e.g., your home
page). Make sure you set MASTER_SITES to
reflect your choice.If you
cannot find somewhere convenient and reliable to put the distfile
(if you are a FreeBSD committer, you can just put it in your
public_html/ directory on
freefall),
we can “house” it ourselves by putting
- it on ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
+ it on ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as MASTER_SITE_LOCAL. Send mail to
the &a.ports;if you are not sure what to do.If your port's distfile changes all the time for no good
reason, consider putting the distfile in your home page and
listing it as the first MASTER_SITES. This
will prevent users from getting checksum
mismatch errors, and also reduce the workload of
maintainers of our ftp site. Also, if there isonly one master
site for the port, it is recommended that you house a backup at
your site and list it as the second
MASTER_SITES.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
DISTDIR. Do not worry if
- they come from site other than where you got the main source
+ they come from a site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of PATCHFILES below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as “plug-and-play”
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-xx where
xx denotes the sequence in which
the patches will be applied — these are done in
alphabetical order, thus
aa first, ab second and so on. These files
should be stored in PATCHDIR, from where they will be
automatically applied. All patches should be relative to
WRKSRC (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier,
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing WRKSRC/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow “overnight builds” to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).It is also recommended that if there are reasonable default
answers to the questions, you check the
PACKAGE_BUILDING variable and turn off the
interactive script when it is set. This will allow us to build
the packages for CD-ROMs and ftp.Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a sample
Makefile in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in DISTDIR as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set DISTNAME to be the base name of
your port. The default rules expect the distribution file
list (DISTFILES) to be
named DISTNAMEEXTRACT_SUFX which, if it is a normal tarball, is going to be
something like foozolix-1.0.tar.gz for a setting of DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/DISTNAME, e.g. work/foozolix-1.0/.All this behavior can be overridden, of course; it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set DISTFILES explicitly. If only a
subset of DISTFILES are
actual extractable archives, then set them up in EXTRACT_ONLY, which will override
the DISTFILES list when
it comes to extraction, and the rest will be just left in
DISTDIR for later
use.PKGNAMEIf DISTNAME does not conform to our guidelines for a good package
name, you should set the PKGNAME
variable to something better. See the abovementioned guidelines
for more details.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable CATEGORIES. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories and pick the
ones that are suitable for your port.This list also determines where in the ports tree the port
is imported. If you put more than one category here, it is
assumed that the port files will be put in the subdirectory with
the name in the first category. See the categories section for
more discussion about how to pick the right categories.If you port truly belongs to something that is different
from all the existing ones, you can even create a new category
name. In that case, please send mail to the &a.ports; to propose
a new category.There is no error checking for category
names. make package will happily create a
new directory if you mustype the category name, so be
careful!MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in MASTER_SITES. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with FETCH if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set PATCHFILES to the names of the
files and PATCH_SITES to
the URL of the directory that contains them (the format is the
same as MASTER_SITES).If the patch is not relative to the top of the source tree
(i.e., WKRSRC) because it
contains some extra pathnames, set PATCH_DIST_STRIP accordingly.
- For instance, if all the pathnames in the patch has an extra
+ For instance, if all the pathnames in the patch have an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
PATCHFILES. If that is
the case, add the name and the location of the patch tarball
to DISTFILES and
MASTER_SITES. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the PATCHDIR directory and calling it
patch-xx.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to MAINTAINER
on Makefiles section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine. There are also some
pre-supported dependency variables for common cases, plus a few
more to control the behaviour of dependencies.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir:target tuples where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available, and
target is the target to call in
that directory. For example,
LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install
will check for a shared jpeg library with
major version 9, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found. The target part can be
omitted if it is equal to DEPENDS_TARGET
(which defaults to install).The lib part is an argument
given to ldconfig -r | grep -wF. There
shall be no reqular expressions in this variable.The dependency is checked twice, once from within the
extract target and then from within
the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir:target tuples where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available, and
target is the target to call in
that directory. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
will check if the file or directory
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish8.0 is in your search path, and
descend into the x11-toolkits/tk80 subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system. The
target part can be omitted if it is
the same DEPENDS_TARGET.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir:target tuples.
For example,
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.“build” here means everything from extracting to
compilation. The dependency is checked from within the
extract target. The
target part can be omitted if it
is the same as DEPENDS_TARGETFETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir:target tuples. For
example,
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the
fetch target. The
target part can be omitted if it is
the same as DEPENDS_TARGET.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted in addition to having
them installed, then use this variable. This is a list of
dir:target, as there is nothing to check, unlike the previous four. The target part can be omitted if it is the same as DEPENDS_TARGET.Common dependency variablesDefine USE_XLIB=yes if your port
requires the X Window System to be installed (it is implied by
USE_IMAKE). Define
USE_GMAKE=yes if your port requires GNU
make instead of BSD
make. Define
USE_AUTOCONF=yes if your port requires GNU
autoconf to be run. Define USE_QT=yes if
your port uses the latest qt toolkit. Use
USE_PERL5=yes if your port requires version
5 of the perl language. (The last is especially important since
some versions of FreeBSD has perl5 as part of the base system
while others don't.)Notes on dependenciesAs mentioned above, the default target to call when a
dependency is required is
DEPENDS_TARGET. It defaults to
install. This is a user variable; is is
never defined in a port's Makefile. If
your port needs a special way to handle a dependency, use the
:target part of the
*_DEPENDS variables instead of redefining
DEPENDS_TARGET.When you type make clean, its
dependencies are automatically cleaned too. If you do not wish
this to happen, define the variable
NOCLEANDEPENDS in your environment.To depend on another port unconditionally, it is customary
to use the string nonexistent as the first
field of BUILD_DEPENDS or
RUN_DEPENDS. Use this only when you need to
the to get to the source of the other port. You can often save
compilation time by specifying the target too. For
instance
BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract
will always descend to the JPEG port and extract it.Do not use DEPENDS unless there is no
other way the behaviour you want can be accomplished. It will
cause the other port to be always build (and installed, by
default), and the dependency will go into the packages as
- well. If this is really what you need, I recommend you to
+ well. If this is really what you need, I recommend you
write it as BUILD_DEPENDS and
RUN_DEPENDS instead—at least the
intention will be clear.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses
configure, set
HAS_CONFIGURE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes (this implies
HAS_CONFIGURE). If you want to give some
extra arguments to configure (the default
argument list --prefix=${PREFIX} for
GNU configure and empty for non-GNU
configure), set those extra arguments in
CONFIGURE_ARGS. If your package uses GNU
autoconf, set
USE_AUTOCONF=yes. This implies
GNU_CONFIGURE, and will cause
autoconf to be run before
configure.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.
If the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>If your port's source Makefile has
something else than all as the main
build target, set ALL_TARGET
accordingly. Same goes for install and
INSTALL_TARGET.Special considerationsThere are some more things you have to take into account when
you create a port. This section explains the most common of
those.ldconfigIf your port installs a shared library, add a
post-install target to your
Makefile that runs
${LDCONFIG} -m on the directory where
the new library is installed (usually
PREFIX/lib) to register
it into the shared library cache.Also, add a matching @exec /sbin/ldconfig
-m and @unexec /sbin/ldconfig -R
pair to your pkg/PLIST file so that a user
who installed the package can start using teh shared libraru
immediately and deinstallation will not cause the system to
still believe the library is there. These lines should
immediately follow the line for the shared library itself, as
in:
lib/libtvl80.so.1
@exec /sbin/ldconfig -m %D/lib
@unexec /sbin/ldconfig -RNever, ever, ever add a line that says
ldconfig without any arguments to your
Makefile or
pkg/PLIST. This will reset the shared
libraru cache to the contents of /usr/lib
only, and will royally screw up the user's machine ("Help, xinit
does not run anymore after I install this port!"). Anybody who
does this will be shot and cut in 65,536 pieces by a rusty knife
and have is liver chopped out by a bunch of crows and will
eternally rot to death in the deepest bowels of hell (not
necessarily in that order…)ELF support
- Since FreeBSD is moving to ELF from 3.0-release onwards,
+ Since FreeBSD is moving to ELF shortly after 3.0-release,
we need to convert many ports that build shared libraries
to support ELF. Complicating this task is that a 3.0
system can run as both ELF and a.out, and that there will
be one more release (2.2.8) from the 2.2 branch. Below
are the guidelines on how to convert a.out only ports to
support both a.out and ELF compilation.Some part of this list is only applicable during the
conversion, but will be left here for awhile for reference
in case you have come across some old port you wish to
upgrade.Moving a.out libraries out of the wayA.out libraries should be moved out of
/usr/local/lib and similar to an
aout subdirectory. (If you don't move them
out of the way, ELF ports will happily overwrite a.out libraries.)
The move-aout-libs target in the -current
src/Makefile (called from
aout-to-elf) will do this for you. It
will only move a.out libs so it is safe to call it on a system
with both ELF and a.out libs in the standard directories.FormatThe ports tree will build packages in the format the machine
is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending
on what `objformat` returns. Also, once users
move a.out libraries to a subdirectory, building a.out libraries
will be unsupported. (I.e., it may still work if you know what you
are doing, but you are on your own.)If a port only works for a.out, set
BROKEN_ELF to a string describing the reason
why. Such ports will be skipped during a build on an ELF
system.PORTOBJFORMATbsd.port.mk will set
PORTOBJFORMAT to aout or
elf and export it in the environments
CONFIGURE_ENV, SCRIPTS_ENV and
MAKE_ENV. (It's always going to be
aout in -stable). It is also passed to
PLIST_SUB as
PORTOBJFORMAT=${PORTOBJFORMAT}. (See comment
on ldconfig lines below.)The variable is set using this line in
bsd.port.mk:
PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aoutPorts' make processes should use this variable to decide what
to do. However, if the port's configure
script already automatically detects an ELF system, it is not
necessary to refer to PORTOBJFORMAT.Building shared librariesThe following are differences in handling shared
libraries for a.out and ELF.Shared library versionsAn ELF shared library should be called
libfoo.so.M
where M is the single version
number, and an a.out library should be called
libfoo.so.M.N where M is the major version and N is the the minor version number. Do not mix those; never install an ELF shared library called libfoo.so.N.M or an a.out shared library (or symlink) called libfoo.so.N.Linker command linesAssuming cc -shared is used rather than
ld directly, the only difference is that
you need to add
on the command line for ELF.You need to install a symlink from
libfoo.so to
libfoo.so.N to
make ELF linkers happy. Since it should be listed in
PLIST too, and it won't hurt in the a.out
case (some ports even require the link for dynamic loading), you
should just make this link regardless of the setting of
PORTOBJFORMAT.LIB_DEPENDSAll port Makefiles are edited to remove minor numbers from
LIB_DEPENDS, and also to have the regexp
support removed. (E.g., foo\\.1\\.\\(33|40\\)
becomes foo.2.) They will be matched using
grep -wF.PLISTPLIST should contain the short (ELF)
shlib names if the a.out minor number is zero, and the long
(a.out) names otherwise. bsd.port.mk will
automatically add .0 to the end of short shlib
lines if PORTOBJFORMAT equals
aout, and will delete the minor number from
long shlib names if PORTOBJFORMAT equals
elf.In cases where you really need to install shlibs with two
versions on an ELF system or those with one version on an a.out
system (for instance, ports that install compatibility libraries
for other operating systems), define the variable
NO_FILTER_SHLIBS. This will turn off the
editing of PLIST mentioned in the previous
paragraph.ldconfigThe ldconfig line in Makefiles should read:
${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....In PLIST it should read;
@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ...
@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -RThis is to ensure that the correct ldconfig
will be called depending on the format of the package, not the
default format of the system.MASTERDIRIf your port needs to build slightly different versions of
packages by having a variable (for instance, resolution, or paper
size) take different values, create one subdirectory per package
to make it easier forusers to see what to do, but try to share as
many files as possible between ports. Typically you only need a
very short Makefile in all but one of the
directories if you use variables cleverly. In the sole
Makefiles, you can use
MASTERDIR to specify the directory where the
rest of the files are. Also, use a variable as part of
PKGNAME
so the packages will have different names.This will be best demonstrated by an example. This is part of
japanese/xdvi300/Makefile;
PKGNAME= ja-xdvi${RESOLUTION}-17
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endifjapanese/xdvi300 also has all the regular
patches, package files, etc. If you type make
there, it will take the default value for the resolution (300) and
build the port normally.As for other resolutions, this is the
entirexdvi118/Makefile;
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile(xdvi240/Makefile and
xdvi400/Makefile are similar). The
MASTERDIR definition tells
bsd.port.mk that the refulat set of
subdirectories like PATCHDIR and
PKGDIR are to be found under
xdvi300. The
RESOLUTION=118 line will override the
RESOLUTION=300 line in
xdvi300/Makefile and the port will be built
with resolution set to 118.Shared library versionsFirst, please read our policy
on shared library versioning to understand
what to do with shared library versions in general. Do
not blindly assume software authors know what they are
doing; many of them do not. It is very important that
these details are carefully considered, as we have quite a
unique situation where we are trying to have dozens of
potentially incompatible software pairs co-exist.
Careless port imports have caused great trouble regarding
shared libraries in the past (ever wondered why the port
jpeg-6b has a shared library version of 9.0?).
If in doubt, send a message to the &a.ports;. Most of the
time, your job ends by determining the right shared
library version and making appropriate patches to
implement it.However, if there is a port which is a different version
of the same software already in the tree, the situation is
much more complex. In short, the FreeBSD implementation
does not allow the user to specify to the linker which
version of shared library to link against (the linker will
always pick the highest numbered version). This means, if
there is a libfoo.so.3.2 and libfoo.so.4.0 in
the system, there is no way to tell the linker to link a
particular application to libfoo.so.3.2. It is
essentially completely overshadowed in terms of
compilation-time linkage. In this case, the only solution
is to rename the base part of the shared library. For
instance, change libfoo.so.4.0 to
libfoo4.so.1.0 so both version 3.2 and 4.0 can be
linked from other ports.ManpagesThe MAN[1-9LN] variables will automatically
add any manpages to pkg/PLIST (this means you
must not list manpages in the
PLIST—see generating PLIST for more). It
also makes the install stage automatically compress or uncompress
manpages depending on the setting of
NOMANCOMPRESS in
/etc/make.conf.To specify whether the manpages are compressed upon
installation, use the MANCOMPRESSED variable.
This variable can take three values, yes,
no and maybe.
yes means manpages are already installed
compressed, no means they are not, and
maybe means the software already respects the
value of NOMANCOMPRESS so
bsd.port.mk does not have to do anything
special.MANCOMPRESSED is automatically set to
yes if USE_IMAKE is set and
NO_INSTALL_MANPAGES is not set, and to
no otherwise. You don't have to explicitly
define it unless the default is not suitable for your port.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages in
certain sections go in a non-standard place, such as some Perl
modules ports, you can set individual man paths using
MANsectPREFIX (where
sect is one of 1-9,
L or N).If your manpages go to language-specific subdirectories, set
the name of the languages to MANLANG. The
value of this variable defaults to "" (i.e.,
English only).Here is an example that puts it all together.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yesThis states that six files are installed by this port;
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gzPorts that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is
a free clone reported to be able to run many applications in
x11-toolkits/lesstif) to compile. Since
it is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically (for people who are compiling from the port) or
statically (for people who distribute packages).REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.MOTIFLIBThis variable will be set by
bsd.port.mk to be the appropriate reference
to the Motif library. Please patch the source to use this
wherever the Motif library is referenced in the
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its Makefile
or Imakefile, simply substitute
${MOTIFLIB} for
it.If the port uses XmClientLibs
in its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands to
-L/usr/X11R6/lib -lXm or
/usr/X11R6/lib/libXm.a, so there is no need
to add -L or -l in
front.X11 fontsIf your port installs fonts for the X Window system, put them
in
X11BASE/lib/X11/fonts/local.
This directory is new to XFree86 release 3.3.3. If it does not
exist, please create it, and print out a message urging the user
to update their XFree86 to 3.3.3 or newer, or at least add this
directory to the font path in
/etc/XF86Config.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info
to add and delete entries to the dir file. If
your port installs any info documents, please follow this
instructions so your port/package will correctly update the user's
PREFIX/info/dir
file. (Sorry for the length of this section, but is it imperative
to weave all the info files together. If done correctly, it will
produce a beautiful listing, so please bear
with me!First, this is what you (as a porter) need to know&prompt.user; install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
:
--entry=TEXT Insert TEXT as an Info directory entry.
:
--section=SEC Put this file's entries in section SEC of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995
+++ ./man/vip.texi Tue May 20 01:28:33 1997
@@ -2,6 +2,10 @@
@setfilename ../info/vip
@settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry
+* VIP: (vip). A VI-emulation for Emacs.
+@end direntry
@iftex
@finalout
:The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/04/15 06:32:12
@@ -15,9 +15,6 @@
man/man1/emacs.1.gz
man/man1/etags.1.gz
man/man1/ctags.1.gz
-@unexec cp %D/info/dir %D/info/dir.bak
-info/dir
-@unexec cp %D/info/dir.bak %D/info/dir
info/cl
info/cl-1
info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+ if [ ! -f ${PREFIX}/info/dir ]; then \
+ ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \
+ fi
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/05/20 10:25:12 1.17
@@ -16,7 +14,15 @@
man/man1/etags.1.gz
man/man1/ctags.1.gz
+@unexec install-info --delete %D/info/emacs %D/info/dir
:
+@unexec install-info --delete %D/info/ccmode %D/info/dir
info/cl
info/cl-1
@@ -87,6 +94,18 @@
info/viper-3
info/viper-4
+@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
+@exec install-info %D/info/emacs %D/info/dir
:
+@exec install-info %D/info/ccmode %D/info/dir
libexec/emacs/19.34/i386--freebsd/cvtmail
libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :). Check the dir file before and after each
step.The pkg/ subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.MESSAGEIf you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capability is often useful to display additional installation
steps to be taken after a pkg_add or to display
licensing information.The pkg/MESSAGE file does not need to
be added to pkg/PLIST. Also, it will not get
automatically printed if the user is using the port, not the
package, so you should probably display it from the
post-install target yourself.INSTALL
- If your port needs execute commands when the binary package is
- installed with pkg_add you can do with via the
+ If your port needs to execute commands when the binary package is
+ installed with pkg_add you can do this via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice by
pkg_add. The first time will as
INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be
tested to determine which mode the script is being run in. The
PKG_PREFIX environmental variable will be set to
the package installation directory. See pkg_add1 for additional
information.This script is not run automatically if you install the port
with make install. If you are depending on
- it being run, you will have to explicitly call it on your port's
+ it being run, you will have to explicitly call it from your port's
Makefile.REQIf your port needs to determine if it should install or not,
you can create a pkg/REQ
“requirements” script. It will be invoked
automatically at installation/deinstallation time to determine
whether or not installation/deinstallation should proceed.Changing PLIST based on make variablesSome ports, particularly the p5- ports, need to change their
PLIST depending on what options they are
configured with (or version of perl, in the case of p5- ports). To
make this easy, any instances in the PLIST of
%%OSREL%%, %%PERL_VER%%, and
%%PERL_VERSION%% will be substituted for
appropriately. The value of %%OSREL%% is the
numeric revision of the operating system (e.g.,
2.2.7). %%PERL_VERSION%% is
the full version number of perl (e.g., 5.00502)
and %%PERL_VER%% is the perl version number
minus the patchlevel (e.g., 5.005).If you need to make other substitutions, you can set the
PLIST_SUB variable with a list of
VAR=VALUE
pairs and instances of
%%VAR%%' will be
substituted with VALUE in the
PLIST.For instance, if you have a port that installs many files in
a version-specific subdirectory, you can put something
like
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
in the Makefile and use
%%OCTAVE_VERSION%% wherever the version shows
up in PLIST. That way, when you upgrade the
port, you will not have to change dozens (or in some cases,
hundreds) of lines in the PLIST.This substitution (as well as addition of any man pages) will be done
between the do-install and
post-install targets, by reading from
PLIST and writing to
TMPPLIST (default:
WRKDIR/.PLIST.mktmp). So
if your port builds PLIST on the fly, do so in
or before do-install. Also, if your port
needs to edit the resulting file, do so in
post-install to a file named
TMPPLIST.
+
+
+ Changing the names of files in the
+ pkg subdirectory
+
+ All the filenames in the pkg subdirectory
+ are defined using variables so you can change them in your
+ Makefile if need be. This is especially useful when you
+ are sharing the same pkg subdirectory among
+ several ports or have to write to one of the above files (see
+ writing to places other than
+ WRKDIR for why it is a bad idea to
+ write directly in to the pkg
+ subdirectory.
+
+ Here is a list of variable names and their default
+ values.
+
+
+
+
+
+ Variable
+ Default value
+
+
+
+
+
+ COMMENT
+ ${PKGDIR}/DESCR
+
+
+
+ DESCR
+ ${PKGDIR}/DESCR
+
+
+
+ PLIST
+ ${PKGDIR}/PLIST
+
+
+
+ PKGINSTALL
+ ${PKGDIR}/PKGINSTALL
+
+
+
+ PKGDEINSTALL
+ ${PKGDIR}/PKGDEINSTALL
+
+
+
+ PKGREQ
+ ${PKGDIR}/REQ
+
+
+
+ PKGMESSAGE
+ ${PKGDIR}/MESSAGE
+
+
+
+
+
+ Please change these variables rather than overriding
+ PKG_ARGS. If you change
+ PKG_ARGS, those files will not correctly be
+ installed in /var/db/pkg upon install from a
+ port.
+
-
+
Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
- can do with them vary a lot, depending on the exact wordings of
+ can do with them varies a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a “do not sell for profit” type of
license, set the variable NO_CDROM to a
string describing the reason why. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE to a string describing the
reason why. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a “no commercial use” license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (e.g., if your modified port
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category ports). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.You should check your own port
against this list, but you can also check ports in the PR
database that others have submitted. Submit any comments on
ports you check as described in Bug
Reports and General Commentary. Checking ports in
the PR database will both make it faster for us to commit them,
and prove that you know what you are doing.Strip BinariesDo strip binaries. If the original source already strips the
binaries, fine; otherwise you should add a
post-install rule to to it yourself. Here is an
example;
post-install:
strip ${PREFIX}/bin/xdlUse the file1 command on the installed executable to check
whether the binary is stripped or not. If it does not say
not stripped, it is stripped.INSTALL_* macrosDo use the macros provided in bsd.port.mk
to ensure correct modes and ownership of files in your own
*-install targets. They are:INSTALL_PROGRAM is a command to install
binary executables.INSTALL_SCRIPT is a command to install
executable scripts.INSTALL_DATA is a command to install
sharable data.INSTALL_MAN is a command to install
manpages and other documentation (it doesn't compress
anything).These are basically the install command
with all the appropriate flags. See below for an example on how
to use them.
+
+
+ WRKDIR
+
+ Do not write anything to files outside
+ WRKDIR. WRKDIR is the only
+ place that is guaranteed to be writable during the port build (see
+ compiling ports from CDROM for an
+ example of building ports from a read-only tree). If you need to
+ modigy some file in PKGDIR, do so by redefining a variable, not by
+ writing over it.
+
+
+
+ WRKDIRPREFIX
+
+ Make sure your port honors
+ WRKDIRPREFIX. Most ports don't have to worry
+ about this. In particular, if you are referring to a
+ WRKDIR of another port, note that the correct
+ location is
+ WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such.
+
+ Also, if you are defining WRKDIR yourself,
+ make sure you prepend
+ ${WKRDIRPREFIX}${.CURDIR} in the
+ front.
+ Differentiating operating systems and OS versionsYou may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as general
as possible so that we can back-port code to FreeBSD 1.x systems
and cross-port to other BSD systems such as 4.4BSD from CSRG,
BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file is
already included; if not, add the code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endifto the proper place in the .c file. We
- believe that every system that defines these to symbols has
+ believe that every system that defines these two symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to the
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile
for this method.Once you have sys/param.h
included, you may use:
#if (defined(BSD) && (BSD >= 199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:
#if (defined(BSD) && (BSD >= 199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is
199506 for the 4.4BSD-Lite2 code base. This is
stated for informational purposes only. It should not be used to
- distinguish between version of FreeBSD based only on 4.4-Lite vs.
+ distinguish between versions of FreeBSD based only on 4.4-Lite vs.
versions that have merged in changes from 4.4-Lite2. The
__FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
only affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endifRelease_FreeBSD_version2.0-RELEASE1194112.1-currents199501, 1995032.0.5-RELEASE1995042.2-current before 2.11995082.1.0-RELEASE1995112.2-current before 2.1.51995122.1.5-RELEASE1996072.2-current before 2.1.61996082.1.6-RELEASE1996122.1.7-RELEASE1996122.2-RELEASE2200002.2.1-RELEASE220000 (no change)2.2-STABLE after 2.2.1-RELEASE220000 (no change)2.2-STABLE after texinfo-3.92210012.2-STABLE after top2210022.2.2-RELEASE2220002.2-STABLE after 2.2.2-RELEASE2220012.2.5-RELEASE2250002.2-STABLE after 2.2.5-RELEASE2250012.2-STABLE after ldconfig -R merge2250022.2.6-RELEASE2260002.2.7-RELEASE2270002.2-STABLE after 2.2.7-RELEASE2270012.2-STABLE after semctl(2) change2270022.2.8-RELEASE2280002.2-STABLE after 2.2.8-RELEASE2280013.0-current before mount(2) change3000003.0-current after mount(2) change3000013.0-current after semctl(2) change3000023.0-current after ioctl arg changes3000033.0-current after ELF conversion3000043.0-RELEASE3000053.0-current after 3.0-RELEASE300006
+
+
+ 3.0-stable after 3/4 branch
+ 300007
+
+
+
+ 3.1-RELEASE
+ 310000
+
+
+
+ 3.1-stable after 3.1-RELEASE
+ 310001
+
+
+
+ 4.0-current after 3/4 branch
+ 400000
+ Note that 2.2-STABLE sometimes identifies itself as
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Writing something after
bsd.port.mkDo not write anything after the .include
<bsd.port.mk> line. it usually can be avoided by
including bsd.port.pre.mk somewhere in the
middle of your Makefile and
bsd.port.post.mk at the end.You need to include either the
pre.mk/post.mk pair or
bsd.port.mk only; don't mix these
two.bsd.port.pre.mk only defines a few
variables, which can be used in tests in the
Makefile,
bsd.port.post.mk defines the rest.Here are some important variables defined in
bsd.port.pre.mk (this is not the complete
list, please read bsd.port.mk for the
complete list).VariableDescriptionARCHThe architecture as returned by uname
-m (e.g., i386)OPSYSThe operating system type, as returned by
uname -s (e.g.,
FreeBSD)OSRELThe release version of the operating system (e.g.,
2.1.5 or
2.2.7)OSVERSIONThe numeric version of the operating system, same as
__FreeBSD_version.PORTOBJFORMATThe object format of the system
(aout or elfLOCALBASEThe base of the “local” tree (e.g.,
/usr/local/)X11BASEThe base of the “X11” tree (e.g.,
/usr/X11R6)PREFIXWhere the port installs itself (see more on
PREFIX).If you have to define the variables
USE_IMAKE, USE_X_PREFIX,
or MASTERDIR, do so before including
bsd.port.pre.mk.Here are some examples of things you can write after
bsd.port.pre.mk;
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endifInstall additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
PREFIX/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means PKGNAME minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole PKGNAME.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)Also you can use the pkg/MESSAGE file to
display messages upon installation. See the using
pkg/MESSAGE section for
details.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
Makefile), set DIST_SUBDIR to the name of the
port (PKGNAME without the
version part should work fine). This will change DISTDIR from the default
/usr/ports/distfiles to
/usr/ports/distfiles/DIST_SUBDIR,
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting DISTDIR explicitly in your
Makefile will not accomplish this, so please use DIST_SUBDIR.)This does not affect the MASTER_SITES you define in your
Makefile.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
NO_PACKAGE is
set.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. If you had to edit
configure.in and run
autoconf to regenerate
configure, do not take the diffs of
configure (it often grows to a few thousand
lines!); define USE_AUTOCONF=yes and take the
diffsof configure.in.Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resulting diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to PREFIX. (The value of this
variable will be set to LOCALBASE (default
/usr/local), unless USE_X_PREFIX or USE_IMAKE is set, in which case it
will be X11BASE (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read PREFIX, as this
variable is automatically passed down to every stage of the
build and install processes.Do not set USE_X_PREFIX unless your port
truly require it (i.e., it links against X libs or it needs to
reference files in X11BASE).The variable PREFIX
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles.Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\"
or
-DPAGER=\"${LOCALBASE}/bin/less\"
if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of PREFIX. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
- details, the rule governing /usr pretty
- much applies to /usr/local too. The
+ details, the rules governing /usr pretty
+ much apply to /usr/local too. The
exception are ports dealing with USENET “news”. They may use
PREFIX/news as a destination for
their files.Cleaning up empty directoriesDo make your ports clean up after themselves when they are
deinstalled. This is usually accomplished by adding
@dirrm lines for all directories that are
specifically created by the port. You need to delete
subdirectories before you can delete parent directories.
:
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
:
@dirrm lib/X11/oneko/pixmals
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/onekoHowever, sometimes @dirrm will give you
errors because other ports also share the same subdirectory. You
can call rmdir from @unexec
to remove only empty directories without warning.
@unexec rmdir %D/share/doc/gimp 2>/dev/null || trueThis will neither print any error messages nor cause
pkg_delete to exit abnormally even if
PREFIX/share/doc/gimp is
not empty due to other ports installing some files in there.UIDsIf your port requires a certain user to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at net/cvsup-mirror
for an example.If your port must use the same user/group ID number when it is
installed a binarypackage as when it was compiled, then you mus
choose a free UID from 50 to 99 and register it below. Look at
japanese/Wnn for an example.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/shPlease include a notice when you submit a port (or an
upgrade) that reserves a new UID or GID in this range. This allows
us to keep the list of reserved IDs up to date.Do things rationallyThe Makefile should do things simply and
reasonably. If you can make it a couple of lines shorter or more
readable, then do so. Examples include using a make
.if construct instead of a shell
if construct, not redefining
do-extract if you can redefine
EXTRACT* instead, and using
GNU_CONFIGURE instead of
CONFIGURE_ARGS +=
--prefix=${PREFIX}.Respect CFLAGSThe port should respect the CFLAGS
variable. If it doesn't, please add NO_PACKAGE=ignores
cflags to the Makefile.Configuration filesIf your port requires some configuration files in
PREFIX/etc, do
not just install them and list them in
pkg/PLIST. That will cause
pkg_delete to delete files carefully edited by
the user and a new installation to wipe them out.Instead, install sample files with a suffix
(filename.sample
will work well) and print out a message pointing out that the
user has to copy and edit the file before the software can be made
to work.PortlintDo check your work with portlint
before you submit or commit it.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code. This
will only make your job that much easier for the next
release.MiscellaneaThe files pkg/DESCR,
pkg/COMMENT, and
pkg/PLIST should each be double-checked. If
you are reviewing a port and feel they can be worded better, do
so.Don't copy more copies of the GNU General Public License into
our system, please.Please be careful to note any legal issues! Don't let us
illegally distribute software!If you are stuck…Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample MakefileHere is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). This format is
designed so that the most important information is easy to
locate. We recommend that you use portlint to check the Makefile.
[the header...just to make it easier for us to identify the ports.]
# New ports collection makefile for: xdvi
[the version required header should updated when upgrading a port.]
# Version required: pl18 [things like "1.5alpha" are fine here too]
[this is the date when the first version of this Makefile was created.
Never change this when doing an update of the port.]
# Date created: 26 May 1995
[this is the person who did the original port to FreeBSD, in particular, the
person who wrote the first version of this Makefile. Remember, this should
not be changed when upgrading the port later.]
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
#
# $Id$
[ ^^^^ This will be automatically replaced with RCS ID string by CVS
when it is committed to our repository.]
#
[section to describe the port itself and the master site - DISTNAME
is always first, followed by PKGNAME (if necessary), CATEGORIES,
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be specified too.]
DISTNAME= xdvi
PKGNAME= xdvi-pl18
CATEGORIES= print
[do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros]
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz" form]
EXTRACT_SUFX= .tar.Z
[section for distributed patches -- can be empty]
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[maintainer; *mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug reports - this
person should be the porter or someone who can forward questions to the
original porter reasonably promptly. If you really do not want to have
your address here, set it to "ports@FreeBSD.ORG".]
MAINTAINER= asami@FreeBSD.ORG
[dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm
[this section is for other standard bsd.port.mk variables that do not
belong to any of the above]
[If it asks questions during configure, build, install...]
IS_INTERACTIVE= yes
[If it extracts to a directory other than ${DISTNAME}...]
WRKSRC= ${WRKDIR}/xdvi-new
[If the distributed patches were not made relative to ${WRKSRC}, you
may need to tweak this]
PATCH_DIST_STRIP= -p1
[If it requires a "configure" script generated by GNU autoconf to be run]
GNU_CONFIGURE= yes
[If it requires GNU make, not /usr/bin/make, to build...]
USE_GMAKE= yes
[If it is an X application and requires "xmkmf -a" to be run...]
USE_IMAKE= yes
[et cetera.]
[non-standard variables to be used in the rules below]
MY_FAVORITE_RESPONSE= "yeah, right"
[then the special rules, in the order they are called]
pre-fetch:
i go fetch something, yeah
post-patch:
i need to do something after patch, great
pre-install:
and then some more stuff before installing, wow
[and then the epilogue]
.include <bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like language-name-compiled.specifics-version.numbers.If your DISTNAME
doesn't look like that, set PKGNAME to something in that
format.FreeBSD strives to support the native language of its
users. The language- part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
ja for Japanese, ru for Russian, vi for Vietnamese,
zh for Chinese, ko for Korean and de for German.The name part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a port of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the capital letters are
important to the name (for example, with one-letter names
like R or V) you may use capital letters at your discretion.
There is a tradition of naming Perl 5 modules by prepending
p5- and converting the double-colon separator to a hyphen;
for example, the Data::Dumper module becomes
p5-Data-Dumper. If the software in question has numbers,
hyphens, or underscores in its name, you may include them as
well (like kinput2).If the port can be built with different hardcoded
defaults (usually part of the directory name in a
family of ports), the
-compiled.specifics part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string pl (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a DISTNAME into a suitable PKGNAME:Distribution NamePackage NameReasonmule-2.2.2.mule-2.2.2No changes requiredXFree86-3.1.2XFree86-3.1.2No changes requiredEmiClock-1.0.2emiclock-1.0.2No uppercase names for single programsgmod1.4gmod-1.4Need a hyphen before version numbersxmris.4.0.2xmris-4.0.2Need a hyphen before version numbersrdist-1.3alphardist-1.3aNo strings like alpha
allowedes-0.9-beta1es-0.9b1No strings like beta
allowedv3.3beta021.srctiff-3.3What the heck was that anyway?tvtwmtvtwm-pl11Version string always requiredpiewmpiewm-1.0Version string always requiredxvgr-2.10pl1xvgr-2.10.1pl allowed only when no
major/minor version numbersgawk-2.15.6ja-gawk-2.15.6Japanese language versionpsutils-1.13psutils-letter-1.13Papersize hardcoded at package build timepkfontspkfonts300-1.0Package for 300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to 1.0 (like the piewm example above). Otherwise, ask the
original author or use the date string (yy.mm.dd) as the
version.CategoriesAs you already know, ports are classified in several
categories. But for this to wor, it is important that porters and
users understand what each category and how we deicde what to put in
each category.Current list of categoriesFirst, this is the current list of port categories. Those
marked with an asterisk (*) are
virtual categories—those that do not
have a corresponding subdirectory in the ports tree.For non-virtual categories, you will find a one-line
description in the pkg/COMMENT file in that
subdirectory (e.g.,
archivers/pkg/COMMENT).CategoryDescription
+
+ afterstep*
+ Ports to support AfterStep window manager
+
+
archiversArchiving tools.astroAstronomical ports.audioSound support.benchmarksBenchmarking utilities.biologyBiology-related software.cadComputer aided design tools.chineseChinese language support.commsCommunication software. Mostly software to talk to
your serial port.convertersCharacter code converters.databasesDatabases.deskutilsThings that used to be on the desktop before
computers were invented.develDevelopment utilities. Do not put libraries here just
because they are libraries—unless they truly don't
belong to anywhere else, they shouldn't be in this
category.editorsGeneral editors. Specialized editors go in the
section for those tools (e.g., a mathematical-formula
editor will go in math).elispEmacs-lisp ports.emulatorsEmulators for other operating systems. Terminal
emulators do not belong
here—X-based ones should go to
x11 and text-based ones to either
comms or misc,
depending on the exact functionality.gamesGames.germanGerman language support.graphicsGraphics utilities.japaneseJapanese language support.kde*Ports that form the K Desktop Environment
(kde).koreanKorean language support.langProgramming languages.mailMail software.mathNumerical computation software and other utilities
for mathematics.mboneMBone applications.miscMiscellaneous utilities—basically things that
doesn't belong to anywhere else. This is the only category
that should not appear with any other non-virtual
category. If you have misc with
something else in your CATEGORIES line,
that means you can safely delete misc
and just put the port in that other subdirectory!netMiscellaneous networking software.newsUSENET news software.offix*Ports from the OffiX suite.
- perl5*
- Ports that require perl version 5 to run.
+ palm
+ Software support for the 3Com Palm(tm) series.
-
+
- pilot*
- Software to use with the 3Com PalmPilot.
+ perl5*
+ Ports that require perl version 5 to run.
- plan9
+ plan9*Various programs from Plan9.printPrinting software. Desktop publishing tools
(previewers, etc.) belong here too.python*Software written in python.russianRussian language support.securitySecurity utilities.shellsCommand line shells.sysutilsSystem utilities.tcl75*Ports that use tcl version 7.5 to run.tcl76*Ports that use tcl version 7.6 to run.tcl80*Ports that use tcl version 8.0 to run.tcl81*Ports that use tcl version 8.1 to run.textprocText processing utilities. It does not include
desktop publishing tools, which go to print/.tk41*Ports that use tk version 4.1 to run.tk42*Ports that use tk version 4.2 to run.tk80*Ports that use tk version 8.0 to run.tk81*Ports that use tk version 8.1 to run.vietnameseVietnamese language support.
+
+ windowmaker*
+ Ports to support the WindowMaker window
+ manager
+
+
wwwSoftware related to the World Wide Web. HTML language
support belong here too.x11The X window system and friends. This category is
only for software that directly support the window system.
Do not put regular X applications here. If your port is
an X application, define USE_XLIB
(implied by USE_IMAKE) and put it in
appropriate categories. Also, many of them go into other
x11-* categories (see below).x11-clocksX11 clocks.x11-fmX11 file managers.x11-fontsX11 fonts and font utilities.x11-toolkitsX11 toolkits.x11-wmX11 window managers.Choosing the right categoryAs many of the categories overlap, you often have to choose
which of the categories should be the primary category of your
port. There are several rules that govern this usse. Here is the
list of priorities, in decreasing order of precedence.Language specific categories alwasys come first. For
example, if your port installs Japanese X11 fonts, then your
CATEGORIES line would read
japanese x11.Specific categories win over less-specific ones. For
instance, an HTML editor should be listed as www
editors, not the other way around. Also, you don't
need to list net when the port belongs to
either of mail, mbone,
news, security, or
www.x11 is used as a secondary category
only when the primary category is a natural language. In
particular, you should not put x11 in the
category line for X applications.If your port truly does not belong anywhere else, put it
in misc.If you are not sure about the category, please put a comment
to that effect in your send-pr submission so we
can discuss it before import it. (If you are a committer, send a
note &a.ports; so we can discuss it first—too often new
ports are imported to a wrong category only to be moved right
away.)Changes to this document and the ports systemIf you maintain a lot of ports, you should consider following
the &a.ports;. Important changes to
the way ports work will be announced there. You can always
find more detailed information on the latest changes by
looking at
the bsd.port.mk CVS log.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)
diff --git a/en_US.ISO8859-1/share/sgml/authors.ent b/en_US.ISO8859-1/share/sgml/authors.ent
index 80e0daca31..374e7dca88 100644
--- a/en_US.ISO8859-1/share/sgml/authors.ent
+++ b/en_US.ISO8859-1/share/sgml/authors.ent
@@ -1,326 +1,338 @@
abial@FreeBSD.ORG">
ache@FreeBSD.ORG">
adam@FreeBSD.ORG">
alex@freebsd.org">
amurai@FreeBSD.ORG">
andreas@FreeBSD.ORG">
archie@FreeBSD.ORG">
asami@FreeBSD.ORG">
ats@FreeBSD.ORG">
awebster@pubnix.net">
bde@FreeBSD.ORG">
billf@FreeBSD.ORG">
brandon@FreeBSD.ORG">
brian@FreeBSD.ORG">
cawimm@FreeBSD.ORG">
charnier@FreeBSD.ORG">
chuckr@glue.umd.edu">
chuckr@FreeBSD.ORG">
cracauer@FreeBSD.ORG">
csgr@FreeBSD.ORG">
cwt@FreeBSD.ORG">
danny@FreeBSD.ORG">
darrenr@FreeBSD.ORG">
dg@FreeBSD.ORG">
davidn@blaze.net.au">
dburr@FreeBSD.ORG">
des@FreeBSD.ORG">
dfr@FreeBSD.ORG">
dillon@FreeBSD.ORG">
dima@FreeBSD.ORG">
+dirk@FreeBSD.ORG">
+
Dirk.vanGulik@jrc.it">
dt@FreeBSD.ORG">
dwhite@FreeBSD.ORG">
dufault@FreeBSD.ORG">
dyson@FreeBSD.ORG">
perhaps@yes.no">
ejc@FreeBSD.ORG">
erich@FreeBSD.ORG">
faq@freebsd.org">
fenner@FreeBSD.ORG">
flathill@FreeBSD.ORG">
+foxfair@FreeBSD.ORG">
+
fsmp@FreeBSD.ORG">
+gallatin@FreeBSD.ORG">
+
gclarkii@FreeBSD.ORG">
gena@NetVision.net.il">
ghelmer@cs.iastate.edu">
gibbs@FreeBSD.ORG">
mjacob@FreeBSD.ORG">
gj@FreeBSD.ORG">
gpalmer@FreeBSD.ORG">
graichen@FreeBSD.ORG">
grog@FreeBSD.ORG">
gryphon@healer.com">
guido@FreeBSD.ORG">
hanai@FreeBSD.ORG">
handy@sxt4.physics.montana.edu">
helbig@FreeBSD.ORG">
-hm@kts.org">
+hm@FreeBSD.ORG">
hoek@FreeBSD.ORG">
hosokawa@FreeBSD.ORG">
hsu@FreeBSD.ORG">
imp@FreeBSD.ORG">
itojun@itojun.org">
jb@cimlogic.com.au">
jdp@FreeBSD.ORG">
jehamby@lightside.com">
jfieber@FreeBSD.ORG">
james@nexis.net">
jgreco@FreeBSD.ORG">
jhay@FreeBSD.ORG">
jkh@FreeBSD.ORG">
jkoshy@FreeBSD.ORG">
jlemon@FreeBSD.ORG">
john@starfire.MN.ORG">
jlrobin@FreeBSD.ORG">
jmacd@FreeBSD.ORG">
jmb@FreeBSD.ORG">
jmg@FreeBSD.ORG">
jmz@FreeBSD.ORG">
joerg@FreeBSD.ORG">
john@FreeBSD.ORG">
jraynard@freebsd.org">
jseger@freebsd.org">
julian@FreeBSD.ORG">
jvh@FreeBSD.ORG">
karl@FreeBSD.ORG">
kato@FreeBSD.ORG">
kelly@fsl.noaa.gov">
ken@FreeBSD.ORG">
kjc@FreeBSD.ORG">
kuriyama@FreeBSD.ORG">
lars@FreeBSD.ORG">
ljo@FreeBSD.ORG">
luoqi@FreeBSD.ORG">
markm@FreeBSD.ORG">
martin@FreeBSD.ORG">
max@FreeBSD.ORG">
mark@vmunix.com">
mbarkah@FreeBSD.ORG">
mckay@FreeBSD.ORG">
mckusick@FreeBSD.ORG">
md@bsc.no">
+mks@FreeBSD.ORG">
+
motoyuki@FreeBSD.ORG">
mph@FreeBSD.ORG">
mpp@FreeBSD.ORG">
msmith@FreeBSD.ORG">
nate@FreeBSD.ORG">
nectar@FreeBSD.ORG">
+newton@FreeBSD.ORG">
+
n_hibma@FreeBSD.ORG">
nik@FreeBSD.ORG">
nsj@FreeBSD.ORG">
obrien@FreeBSD.ORG">
olah@FreeBSD.ORG">
opsys@open-systems.net">
paul@FreeBSD.ORG">
pb@fasterix.freenix.org">
pds@FreeBSD.ORG">
peter@FreeBSD.ORG">
phk@FreeBSD.ORG">
pjchilds@imforei.apana.org.au">
proven@FreeBSD.ORG">
pst@FreeBSD.ORG">
rgrimes@FreeBSD.ORG">
rhuff@cybercom.net">
ricardag@ag.com.br">
rich@FreeBSD.ORG">
rnordier@FreeBSD.ORG">
roberto@FreeBSD.ORG">
rse@FreeBSD.ORG">
sada@FreeBSD.ORG">
scrappy@FreeBSD.ORG">
se@FreeBSD.ORG">
sef@FreeBSD.ORG">
+simokawa@FreeBSD.ORG">
+
smace@FreeBSD.ORG">
smpatel@FreeBSD.ORG">
sos@FreeBSD.ORG">
stark@FreeBSD.ORG">
stb@FreeBSD.ORG">
steve@FreeBSD.ORG">
swallace@FreeBSD.ORG">
tedm@FreeBSD.ORG">
tegge@FreeBSD.ORG">
tg@FreeBSD.ORG">
thepish@FreeBSD.ORG">
torstenb@FreeBSD.ORG">
truckman@FreeBSD.ORG">
ugen@FreeBSD.ORG">
uhclem@FreeBSD.ORG">
ulf@FreeBSD.ORG">
vanilla@FreeBSD.ORG">
wes@FreeBSD.ORG">
whiteside@acm.org">
wilko@yedi.iaf.nl">
wlloyd@mpd.ca">
wollman@FreeBSD.ORG">
wosch@FreeBSD.ORG">
wpaul@FreeBSD.ORG">
yokota@FreeBSD.ORG">
diff --git a/en_US.ISO_8859-1/books/handbook/authors.ent b/en_US.ISO_8859-1/books/handbook/authors.ent
index 80e0daca31..374e7dca88 100644
--- a/en_US.ISO_8859-1/books/handbook/authors.ent
+++ b/en_US.ISO_8859-1/books/handbook/authors.ent
@@ -1,326 +1,338 @@
abial@FreeBSD.ORG">
ache@FreeBSD.ORG">
adam@FreeBSD.ORG">
alex@freebsd.org">
amurai@FreeBSD.ORG">
andreas@FreeBSD.ORG">
archie@FreeBSD.ORG">
asami@FreeBSD.ORG">
ats@FreeBSD.ORG">
awebster@pubnix.net">
bde@FreeBSD.ORG">
billf@FreeBSD.ORG">
brandon@FreeBSD.ORG">
brian@FreeBSD.ORG">
cawimm@FreeBSD.ORG">
charnier@FreeBSD.ORG">
chuckr@glue.umd.edu">
chuckr@FreeBSD.ORG">
cracauer@FreeBSD.ORG">
csgr@FreeBSD.ORG">
cwt@FreeBSD.ORG">
danny@FreeBSD.ORG">
darrenr@FreeBSD.ORG">
dg@FreeBSD.ORG">
davidn@blaze.net.au">
dburr@FreeBSD.ORG">
des@FreeBSD.ORG">
dfr@FreeBSD.ORG">
dillon@FreeBSD.ORG">
dima@FreeBSD.ORG">
+dirk@FreeBSD.ORG">
+
Dirk.vanGulik@jrc.it">
dt@FreeBSD.ORG">
dwhite@FreeBSD.ORG">
dufault@FreeBSD.ORG">
dyson@FreeBSD.ORG">
perhaps@yes.no">
ejc@FreeBSD.ORG">
erich@FreeBSD.ORG">
faq@freebsd.org">
fenner@FreeBSD.ORG">
flathill@FreeBSD.ORG">
+foxfair@FreeBSD.ORG">
+
fsmp@FreeBSD.ORG">
+gallatin@FreeBSD.ORG">
+
gclarkii@FreeBSD.ORG">
gena@NetVision.net.il">
ghelmer@cs.iastate.edu">
gibbs@FreeBSD.ORG">
mjacob@FreeBSD.ORG">
gj@FreeBSD.ORG">
gpalmer@FreeBSD.ORG">
graichen@FreeBSD.ORG">
grog@FreeBSD.ORG">
gryphon@healer.com">
guido@FreeBSD.ORG">
hanai@FreeBSD.ORG">
handy@sxt4.physics.montana.edu">
helbig@FreeBSD.ORG">
-hm@kts.org">
+hm@FreeBSD.ORG">
hoek@FreeBSD.ORG">
hosokawa@FreeBSD.ORG">
hsu@FreeBSD.ORG">
imp@FreeBSD.ORG">
itojun@itojun.org">
jb@cimlogic.com.au">
jdp@FreeBSD.ORG">
jehamby@lightside.com">
jfieber@FreeBSD.ORG">
james@nexis.net">
jgreco@FreeBSD.ORG">
jhay@FreeBSD.ORG">
jkh@FreeBSD.ORG">
jkoshy@FreeBSD.ORG">
jlemon@FreeBSD.ORG">
john@starfire.MN.ORG">
jlrobin@FreeBSD.ORG">
jmacd@FreeBSD.ORG">
jmb@FreeBSD.ORG">
jmg@FreeBSD.ORG">
jmz@FreeBSD.ORG">
joerg@FreeBSD.ORG">
john@FreeBSD.ORG">
jraynard@freebsd.org">
jseger@freebsd.org">
julian@FreeBSD.ORG">
jvh@FreeBSD.ORG">
karl@FreeBSD.ORG">
kato@FreeBSD.ORG">
kelly@fsl.noaa.gov">
ken@FreeBSD.ORG">
kjc@FreeBSD.ORG">
kuriyama@FreeBSD.ORG">
lars@FreeBSD.ORG">
ljo@FreeBSD.ORG">
luoqi@FreeBSD.ORG">
markm@FreeBSD.ORG">
martin@FreeBSD.ORG">
max@FreeBSD.ORG">
mark@vmunix.com">
mbarkah@FreeBSD.ORG">
mckay@FreeBSD.ORG">
mckusick@FreeBSD.ORG">
md@bsc.no">
+mks@FreeBSD.ORG">
+
motoyuki@FreeBSD.ORG">
mph@FreeBSD.ORG">
mpp@FreeBSD.ORG">
msmith@FreeBSD.ORG">
nate@FreeBSD.ORG">
nectar@FreeBSD.ORG">
+newton@FreeBSD.ORG">
+
n_hibma@FreeBSD.ORG">
nik@FreeBSD.ORG">
nsj@FreeBSD.ORG">
obrien@FreeBSD.ORG">
olah@FreeBSD.ORG">
opsys@open-systems.net">
paul@FreeBSD.ORG">
pb@fasterix.freenix.org">
pds@FreeBSD.ORG">
peter@FreeBSD.ORG">
phk@FreeBSD.ORG">
pjchilds@imforei.apana.org.au">
proven@FreeBSD.ORG">
pst@FreeBSD.ORG">
rgrimes@FreeBSD.ORG">
rhuff@cybercom.net">
ricardag@ag.com.br">
rich@FreeBSD.ORG">
rnordier@FreeBSD.ORG">
roberto@FreeBSD.ORG">
rse@FreeBSD.ORG">
sada@FreeBSD.ORG">
scrappy@FreeBSD.ORG">
se@FreeBSD.ORG">
sef@FreeBSD.ORG">
+simokawa@FreeBSD.ORG">
+
smace@FreeBSD.ORG">
smpatel@FreeBSD.ORG">
sos@FreeBSD.ORG">
stark@FreeBSD.ORG">
stb@FreeBSD.ORG">
steve@FreeBSD.ORG">
swallace@FreeBSD.ORG">
tedm@FreeBSD.ORG">
tegge@FreeBSD.ORG">
tg@FreeBSD.ORG">
thepish@FreeBSD.ORG">
torstenb@FreeBSD.ORG">
truckman@FreeBSD.ORG">
ugen@FreeBSD.ORG">
uhclem@FreeBSD.ORG">
ulf@FreeBSD.ORG">
vanilla@FreeBSD.ORG">
wes@FreeBSD.ORG">
whiteside@acm.org">
wilko@yedi.iaf.nl">
wlloyd@mpd.ca">
wollman@FreeBSD.ORG">
wosch@FreeBSD.ORG">
wpaul@FreeBSD.ORG">
yokota@FreeBSD.ORG">
diff --git a/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
index a549e0ca67..64de53ef79 100644
--- a/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
@@ -1,506 +1,531 @@
BibliographyWhile the manual pages provide the definitive reference for
individual pieces of the FreeBSD operating system, they are notorious
for not illustrating how to put the pieces together to make the whole
operating system run smoothly. For this, there is no substitute for a
good book on UNIX system administration and a good users'
manual.Books & Magazines Specific to FreeBSDInternational books &
Magazines:Using
FreeBSD (in Chinese).FreeBSD for PC 98'ers (in Japanese), published by SHUWA
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.FreeBSD (in Japanese), published by CUTT. ISBN
4-906391-22-2 C3055 P2400E.Complete Introduction to FreeBSD (in Japanese), published by Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E.Personal UNIX Starter Kit FreeBSD (in Japanese), published by ASCII. ISBN 4-7561-1733-3 P3000E.FreeBSD Handbook (Japanese translation), published by
ASCII. ISBN
4-7561-1580-2 P3800E.
- FreeBSD mit Methode (in German), publiched by Computer und
- Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-93211-31-0.
+ FreeBSD mit Methode (in German), published by Computer und
+ Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.
+
+
+ FreeBSD
+ Install and Utilization Manual (in Japanese),
+ published by Mainichi
+ Communications Inc..
+ English language books &
Magazines:The
Complete FreeBSD, published by Walnut Creek
CDROM.Users' GuidesComputer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-075-9Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-076-7UNIX in a Nutshell. O'Reilly
& Associates, Inc., 1990. ISBN
093717520XMui, Linda. What You Need To Know When You Can't
Find Your UNIX System Administrator. O'Reilly
& Associates, Inc., 1995. ISBN 1-56592-104-6Ohio State
University has written a UNIX Introductory Course which is available online in HTML and postscript format.
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ User's Reference Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0088-4
+ P3800E.
+ Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc.,
1997. ISBN 1-56592-236-0Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-080-5Costales, Brian, et al. Sendmail, 2nd
Ed. O'Reilly & Associates, Inc., 1997. ISBN
1-56592-222-0Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly &
Associates, Inc., 1995. ISBN 1-56592-127-5Hunt, Craig. TCP/IP Network
Administration. O'Reilly & Associates, Inc.,
1992. ISBN 0-937175-82-XNemeth, Evi. UNIX System Administration
Handbook. 2nd Ed. Prentice Hall, 1995. ISBN 0131510517Stern, Hal Managing NFS and NIS
O'Reilly & Associates, Inc., 1991. ISBN
0-937175-75-7
-
+
+
+ Jpman Project,
+ Japan FreeBSD Users Group. FreeBSD
+ System Administrator's Manual (Japanese translation).
+ Mainichi
+ Communications Inc., 1998. ISBN4-8399-0109-0
+ P3300E.
+ Programmers' GuidesAsente, Paul. X Window System
Toolkit. Digital Press. ISBN
1-55558-051-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-078-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary
Documents. O'Reilly & Associates, Inc., 1994.
ISBN 1-56592-079-1Harbison, Samuel P. and Steele, Guy L. Jr. C: A
Reference Manual. 4rd ed. Prentice Hall, 1995.
ISBN 0-13-326224-3Kernighan, Brian and Dennis M. Ritchie. The C
Programming Language.. PTR Prentice Hall, 1988.
ISBN 0-13-110362-9Lehey, Greg. Porting UNIX Software.
O'Reilly & Associates, Inc., 1995. ISBN
1-56592-126-7Plauger, P. J. The Standard C
Library. Prentice Hall, 1992. ISBN
0-13-131509-9Stevens, W. Richard. Advanced Programming in the
UNIX Environment. Reading, Mass. :
Addison-Wesley, 1992 ISBN 0-201-56317-7Stevens, W. Richard. UNIX Network
Programming. 2nd Ed, PTR Prentice Hall, 1998. ISBN
0-13-490012-XWells, Bill. “Writing Serial Drivers for UNIX”.
Dr. Dobb's Journal. 19(15), December
1994. pp68-71, 97-99.Operating System InternalsAndleigh, Prabhat K. UNIX System
Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5Jolitz, William. “Porting UNIX to the
386”. Dr.
Dobb's Journal. January 1991-July 1992.Leffler, Samuel J., Marshall Kirk McKusick, Michael J
Karels and John Quarterman The Design and
Implementation of the 4.3BSD UNIX Operating
System. Reading, Mass. : Addison-Wesley,
1989. ISBN 0-201-06196-1Leffler, Samuel J., Marshall Kirk McKusick, The
Design and Implementation of the 4.3BSD UNIX Operating
System: Answer Book. Reading, Mass. :
Addison-Wesley, 1991. ISBN 0-201-54629-9McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation
of the 4.4BSD Operating System. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-54979-4Stevens, W. Richard. TCP/IP Illustrated, Volume
1: The Protocols. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-63346-9Schimmel, Curt. Unix Systems for Modern
Architectures. Reading, Mass. : Addison-Wesley,
1994. ISBN 0-201-63338-8Stevens, W. Richard. TCP/IP Illustrated, Volume
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
Protocols. Reading, Mass. : Addison-Wesley,
1996. ISBN 0-201-63495-3Vahalia, Uresh. UNIX Internals -- The New
Frontiers. Prentice Hall, 1996. ISBN
0-13-101908-2Wright, Gary R. and W. Richard Stevens. TCP/IP
Illustrated, Volume 2: The Implementation.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63354-XSecurity ReferenceCheswick, William R. and Steven M. Bellovin.
Firewalls and Internet Security: Repelling the Wily
Hacker. Reading, Mass. : Addison-Wesley,
1995. ISBN 0-201-63357-4Garfinkel, Simson and Gene Spafford. Practical
UNIX Security. 2nd Ed. O'Reilly & Associates,
Inc., 1996. ISBN 1-56592-148-8Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995.
ISBN 1-56592-098-8Hardware ReferenceAnderson, Don and Tom Shanley. Pentium Processor
System Architecture. 2nd Ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40992-5Ferraro, Richard F. Programmer's Guide to the
EGA, VGA, and Super VGA Cards. 3rd ed. Reading,
Mass. : Addison-Wesley, 1995. ISBN
0-201-62490-7Intel Corporation publishes documentation on their CPUs,
chipsets and standards on their developer web site,
usually as PDF files.Shanley, Tom. 80486 System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40994-1Shanley, Tom. ISA System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40996-8Shanley, Tom. PCI System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40993-3Van Gilluwe, Frank. The Undocumented
PC. Reading, Mass: Addison-Wesley Pub. Co.,
1994. ISBN 0-201-62277-7UNIX HistoryLion, John Lion's Commentary on UNIX, 6th Ed.
With Source Code. ITP Media Group, 1996. ISBN 1573980137Raymond, Eric s. The New Hacker's Dictonary, 3rd
edition. MIT Press, 1996. ISBN
0-262-68092-0 Also known as the Jargon
FileSalus, Peter H. A quarter century of
UNIX. Addison-Wesley Publishing Company, Inc.,
1994. ISBN 0-201-54777-5Simon Garfinkel, Daniel Weise, Steven Strassmann.
The UNIX-HATERS Handbook. IDG Books
Worldwide, Inc., 1994. ISBN 1-56884-203-1Don Libes, Sandy Ressler Life with
UNIX — special edition. Prentice-Hall, Inc.,
1989. ISBN 0-13-536657-7The BSD family tree. 1997. ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree or local on a FreeBSD-current machine.The BSD Release Announcements
collection. 1997. http://www.de.FreeBSD.ORG/de/ftp/releases/Networked Computer Science Technical Reports
Library. http://www.ncstrl.org/Old BSD releases from the Computer Systems Research
group (CSRG). http://www.mckusick.com/csrg/: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last disk holds the final sources plus the SCCS files.Magazines and JournalsThe C/C++ Users Journal. R&D
Publications Inc. ISSN 1075-2838Sys Admin — The Journal for UNIX System
Administrators Miller Freeman, Inc., ISSN
1061-2688
diff --git a/en_US.ISO_8859-1/books/handbook/book.sgml b/en_US.ISO_8859-1/books/handbook/book.sgml
index a4c9c067df..fb72c6e754 100644
--- a/en_US.ISO_8859-1/books/handbook/book.sgml
+++ b/en_US.ISO_8859-1/books/handbook/book.sgml
@@ -1,111 +1,112 @@
%chapters;
%authors;
%mailing-lists;
]>
FreeBSD HandbookThe FreeBSD Documentation ProjectJuly 19981995199619971998The FreeBSD Documentation Project, FreeBSD Inc.Welcome to FreeBSD! This handbook covers the installation and day
to day use of FreeBSD Release &rel.current;. This
manual is a work in progress and is the work of
many individuals. Many sections do not yet exist and some of those
that do exist need to be updated. If you are interested in helping
- with this project, send email to the &a.doc; The latest version of
+ with this project, send email to the &a.doc;. The latest version of
this document is always available from the FreeBSD World Wide Web server.
It may also be downloaded in plain
text, postscript or HTML with HTTP or gzip'd from the FreeBSD FTP server or one of the numerous FreeBSD FTP server or one of the numerous mirror sites. You may also want to
Search the Handbook.Getting Started
&chap.introduction;
&chap.install;
&chap.basics;
&chap.ports
System Administration
&chap.kernelconfig;
&chap.security;
&chap.printing;
&chap.disks;
&chap.backups;
&chap.quotas;
&chap.x11;
&chap.hw;
&chap.l10n;
Network Communications
&chap.serialcomms;
&chap.ppp-and-slip;
&chap.advanced-networking;
&chap.mail;
Advanced topics
&chap.cutting-edge;
&chap.contrib;
&chap.policies;
&chap.kernelopts;
&chap.kerneldebug;
&chap.linuxemu;
&chap.internals;
Appendices
&chap.mirrors;
&chap.bibliography;
&chap.eresources;
&chap.staff;
&chap.pgpkeys;
diff --git a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
index 2dffa913a2..bd3723e510 100644
--- a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
@@ -1,2895 +1,2954 @@
Contributing to FreeBSDContributed by &a.jkh;.So you want to contribute something to FreeBSD? That is great! We
can always use the help, and FreeBSD is one of those systems that
relies on the contributions of its user base in
order to survive. Your contributions are not only appreciated, they
are vital to FreeBSD's continued growth!Contrary to what some people might also have you believe, you do
not need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help
the project!Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product?
Please let us know! We may be able to work cooperatively on some
aspect of it. The free software world is challenging a lot of
existing assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at least give
it a second look.What Is NeededThe following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user
requests we have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If you are
interested in working on one of the tasks you see here, send mail to
the coordinator listed by clicking on their names. If no
coordinator has been appointed, maybe you would like to
volunteer?High priority tasksThe following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:3-stage boot issues. Overall coordination:
&a.hackers;Move userconfig (-c) into 3rd stage boot.Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.Filesystem problems. Overall coordination: &a.fs;Fix the MSDOS file system.Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;Fix the union file system. Coordinator:
&a.dg;Implement kernel and user vm86 support. Coordinator:
&a.jlemon;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;Kernel issues. Overall coordination: &a.hackers;Complete the eisaconf conversion of all existing
drivers.Change all interrupt routines to take a (void *)
instead of using unit numbers.Merge EISA/PCI/ISA interrupt registration
code.Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).Medium priority tasksThe following tasks need to be done, but not with any
particular urgency:Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth Jones ajones@ctron.comMCA support? This should be finalized one way or the
other.Full LKM based driver support/Configuration Manager.Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;Documentation!Reliable operation of the pcic driver (needs
testing).Recognizer and handler for
sio.c (mostly done).Recognizer and handler for
ed.c (mostly done).Recognizer and handler for
ep.c (mostly done).User-mode recognizer and handler (partially
done).Advanced Power Management. Coordinators: &a.msmith; and
&a.phk;APM sub-driver (mostly done).IDE/ATA disk sub-driver (partially done).syscons/pcvt sub-driver.Integration with the PCMCIA/PCCARD drivers
(suspend/resume).Low priority tasksThe following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them
done anytime soon:The first 20 items are from Terry Lambert
terry@lambert.orgAbility to make BIOS calls from protected mode using V86
mode on the processor and return the results via a mapped
interrupt IPC mechanism to the protected mode caller.Drivers built into the kernel that use the BIOS call
mechanism to allow them to be independent of the actual
underlying hardware the same way that DOS is independent of
the underlying hardware. This includes NetWork and ASPI
drivers loaded in DOS prior to BSD being loaded by a
DOS-based loader program, which means potential polling,
which means DOS-not-busy interrupt generation for V86
machines by the protected mode kernel.An image format that allows tagging of such drivers data
and text areas in the default kernel executable so that that
portion of the kernel address space may be recovered at a
later time, after hardware specific protected mode drivers
have been loaded and activated. This includes separation of
BIOS based drivers from each other, since it is better to
run with a BIOS based driver in all cases than to not run at
all.Abstraction of the bus interface mechanism. Currently,
PCMCIA, EISA, and PCI busses are assumed to be bridged from
ISA. This is not something which should be assumed.A configuration manager that knows about PNP events,
including power management events, insertion, extraction,
and bus (PNP ISA and PCMCIA bridging chips) vs. card level
event management.A topological sort mechanism for assigning reassignable
addresses that do not collide with other reassignable and
non-reassignable device space resource usage by fixed
devices.A registration based mechanism for hardware services
registration. Specifically, a device centric registration
mechanism for timer and sound and other system critical
service providers. Consider Timer2 and Timer0 and speaker
services as one example of a single monolithic service
provider.A kernel exported symbol space in the kernel data space
accessible by an LKM loader mechanism that does relocation
and symbol space manipulation. The intent of this interface
is to support the ability to demand load and unload kernel
modules.NetWare Server (protected mode ODI driver) loader and
subservices to allow the use of ODI card drivers supplied
with network cards. The same thing for NDIS drivers and
NetWare SCSI drivers.An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.Splitting of the console driver into abstraction layers,
both to make it easier to port and to kill the X and
ThinkPad and PS/2 mouse and LED and console switching and
bouncing NumLock problems once and for all.Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.Streams to allow the use of commercial streams drivers.Kernel multithreading (requires kernel preemption).Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).A concerted effort at support for portable computers.
This is somewhat handled by changing PCMCIA bridging rules
and power management event handling. But there are things
like detecting internal vs. external display and picking a
different screen resolution based on that fact, not spinning
down the disk if the machine is in dock, and allowing
dock-based cards to disappear without affecting the machines
ability to boot (same issue for PCMCIA).Reorganization of the source tree for multiple platform
ports.A make world that "makes the world" (rename the
current one to make regress if that is all it is good
for).A 4M (preferably smaller!) memory footprint.Smaller tasksMost of the tasks listed in the previous sections require
either a considerable investment of time or an in-depth knowledge
of the FreeBSD kernel (or both). However, there are also many
useful tasks which are suitable for "weekend hackers",
or people without programming skills.If you run FreeBSD-current and have a good Internet
connection, there is a machine current.freebsd.org which
builds a full release once a day — every now and again, try
and install the latest release from it and report any
failures in the process.Read the freebsd-bugs mailing list. There might be a
problem you can comment constructively on or with patches
you can test. Or you could even try to fix one of the
problems yourself.Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even just
completely wrong, let us know. Even better, send us a fix
(SGML is not difficult to learn, but there is no objection
to ASCII submissions).Help translate FreeBSD documentation into your native
language (if not already available) — just send an email to
&a.doc; asking if anyone is working on it. Note that you
are not committing yourself to translating every single
FreeBSD document by doing this — in fact, the documentation
most in need of translation is the installation
instructions.Read the freebsd-questions mailing list and the
newsgroup comp.unix.bsd.freebsd.misc occasionally (or even
regularly). It can be very satisfying to share your
expertise and help people solve their problems; sometimes
you may even learn something new yourself! These forums can
also be a source of ideas for things to work on.If you know of any bugfixes which have been successfully
applied to -current but have not been merged into -stable
after a decent interval (normally a couple of weeks), send
the committer a polite reminder.Move contributed software to
src/contrib in the source tree.Make sure code in src/contrib is up
to date.Look for year 2000 bugs (and fix any you find!)Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.If you have contributed any ports, send your patches
back to the original author (this will make your life easier
when they bring out the next version)Suggest further tasks for this list!How to ContributeContributions to the system generally fall into one or more of
the following 6 categories:Bug reports and general commentaryAn idea or suggestion of general
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
high volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
mailing lists for more
information about this and other mailing lists.If you find a bug or are submitting a specific change, please
report it using the send-pr1program or its
WEB-based
equivalent. Try to fill-in each field of the bug report.
Unless they exceed 65KB, include any patches directly in the
report. Consider compressing them and using
uuencode1 if they exceed 20KB. Upload very large submissions to ftp.freebsd.org:/pub/FreeBSD/incoming/.After filing a report, you should receive confirmation along
with a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to bug-followup@FreeBSD.ORG. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way.If you do not receive confirmation in a timely fashion (3 days
to a week, depending on your email connection) or are, for some
reason, unable to use the send-pr1 command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.Changes to the documentationChanges to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
send-pr as described in
Bug Reports and General
Commentary.Changes to existing source codeAn addition or change to the existing source code is a
somewhat trickier affair and depends a lot on how far out of date
you are with the current state of the core FreeBSD development.
There is a special on-going release of FreeBSD known as
“FreeBSD-current” which is made available in a variety of ways
for the convenience of developers working actively on the system.
See Staying current with FreeBSD
for more information
about getting and using FreeBSD-current.Working from older sources unfortunately means that your
changes may sometimes be too obsolete or too divergent for easy
re-integration into FreeBSD. Chances of this can be minimized
somewhat by subscribing to the &a.announce; and the &a.current;
lists, where discussions on the current state of the system take
place.Assuming that you can manage to secure fairly up-to-date
sources to base your changes on, the next step is to produce a set
of diffs to send to the FreeBSD maintainers. This is done with
the diff1 command, with the “context diff”
form being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; diff -c -r olddir newdir
would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for diff1 for more details.Once you have a set of diffs (which you may test with the
patch1 command), you should submit them for
inclusion with FreeBSD. Use the send-pr1
program as described in
Bug Reports and General
Commentary. Do not just send the diffs to
the &a.hackers; or they will get lost! We greatly appreciate your
submission (this is a volunteer project!); because we are busy, we
may not be able to address it immediately, but it will remain in
the pr database until we do.If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file and run the
uuencode1 program on it. Shar archives are
also welcome.If your change is of a potentially sensitive nature, e.g. you
are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review
first, then you should send it to &a.core; directly rather than
submitting it with send-pr1. The core
mailing list reaches a much smaller group of people who do much of
the day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to
them where it is truly necessary.Please refer to man 9 intro and
man 9 style for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.New code or major value-added packagesIn the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD, it
becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:The BSD copyright. This copyright is most preferred due
to its “no strings attached” nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial
interests who might eventually be inclined to invest
something of their own into FreeBSD.The GNU Public License, or “GPL”. This license is not
quite as popular with us due to the amount of extra effort
demanded of anyone using the code for commercial purposes,
but given the sheer quantity of GPL'd code we currently
require (compiler, assembler, text formatter, etc) it would
be silly to refuse additional contributions under this
license. Code under the GPL also goes into a different part
of the tree, that being /sys/gnu or
/usr/src/gnu, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will be
considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.To place a “BSD-style” copyright on your work, include the
following text at the very beginning of every source code file you
wish to protect, replacing the text between the
%% with the appropriate information.
Copyright (c) %%proper_years_here%%
%%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$For your convenience, a copy of this text can
be found in
/usr/share/examples/etc/bsd-style-copyright.Money, Hardware or Internet accessWe are always very happy to accept donations to further the
cause of the FreeBSD Project and, in a volunteer effort like ours,
a little can go a long way! Donations of hardware are also very
important to expanding our list of supported peripherals since we
generally lack the funds to buy such items ourselves.Donating fundsWhile the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.dg; with the goal of furthering the aims of the FreeBSD
Project and giving it a minimal corporate presence. Any and all
funds donated (as well as any profits that may eventually be
realized by FreeBSD, Inc.) will be used exclusively to further
the project's goals.Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:FreeBSD, Inc.c/o Jordan Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO
box can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to
Jordan Hubbard jkh@FreeBSD.org,
either via email or to the FreeBSD, Inc. postal address given
above.If you do not wish to be listed in our donors section, please specify this
when making your donation. Thanks!Donating hardwareDonations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the donating funds
section.Hardware for which ongoing compliance testing is
desired. We are currently trying to put together a testing
lab of all components that FreeBSD supports so that proper
regression testing can be done with each new release. We
are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a
donation, please contact &a.dg; for information on
which items are still required.Hardware currently unsupported by FreeBSD for which
you would like to see such support added. Please contact
the &a.core; before sending such items as we will need to
find a developer willing to take on the task before we can
accept delivery of new hardware.Donating Internet accessWe can always use new mirror sites for FTP, WWW or cvsup. If
you would like to be such a mirror, please contact the FreeBSD project
administrators admin@FreeBSD.ORG for more information.Donors GalleryThe FreeBSD Project is indebted to the following donors and
would like to publically thank them here!Contributors to the central server
project:The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
freefall.freebsd.org by donating the
following items:Ade
Barkah mbarkah@freebsd.org and his employer, Hemisphere Online,
donated a Pentium Pro (P6) 200Mhz
CPUASA
Computers donated a Tyan
1662 motherboard.Joe McGuckin joe@via.net
of ViaNet
Communications donated a Kingston ethernet controller.Jack
O'Neill jack@diamond.xtalwind.net donated an NCR
53C875 SCSI controller card.Ulf
Zimmermann ulf@Alameda.net of Alameda Networks
donated 128MB of memory, a
4 Gb disk drive and the
case.Direct funding:The following individuals and businesses have generously
contributed direct funding to the project:Annelise
Anderson ANDRSN@HOOVER.STANFORD.EDUMatt
Dillon dillon@best.netEpilogue
Technology CorporationSean Eric FaganDon Scott WildeGianmarco
Giovannelli gmarco@masternet.itJosef C.
Grosch joeg@truenorth.orgRobert T. MorrisChuck
Robey chuckr@freebsd.orgKenneth
P. Stox ken@stox.sa.enteract.com of Imaginary Landscape,
LLC.Dmitry S.
Kohmanyuk dk@dog.farm.orgLaser5
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.Fuki
Shuppan Publishing Co. donated a portion of
their profits from Hajimete no
FreeBSD (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.ASCII
Corp. donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.Yokogawa
Electric Corp has generously donated
significant funding to the FreeBSD project.BuffNET
+
+ Pacific
+ Solutions
+ Hardware contributors:The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:Walnut Creek CDROM for providing the Pentium P5-90
and 486/DX2-66 EISA/VL systems that are being used for
our development work, to say nothing of the network
access and other donations of hardware resources.TRW Financial Systems, Inc. provided 130 PCs, three
68 GB fileservers, twelve Ethernets, two routers and an
ATM switch for debugging the diskless code. They also
keep a couple of FreeBSD hackers alive and busy.
Thanks!Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.&a.chuck; contributed his floppy tape streamer for
experimental work.Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver.Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-)Tekram
Technologies sent one each of their DC-390,
DC-390U and DC-390F FAST and ULTRA SCSI host adapter
cards for regression testing of the NCR and AMD drivers
with their cards. They are also to be applauded for
making driver sources for free operating systems
available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD.Larry M.
Augustin contributed not only a Symbios
Sym8751S SCSI card, but also a set of data books,
including one about the forthcoming Sym53c895 chip with
Ultra-2 and LVD support, and the latest programming
manual with information on how to safely use the
advanced features of the latest Symbios SCSI chips.
Thanks a lot!Christoph
Kukulies kuku@freebsd.org donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.Special contributors:Walnut Creek
CDROM has donated almost more than we can say
(see the
history document for
more details). In particular, we would like to thank
them for the original hardware used for
freefall.FreeBSD.ORG, our primary
development machine, and for
thud.FreeBSD.ORG, a testing and
build box. We are also indebted to them for funding
various contributors over the years and providing us
with unrestricted use of their T1 connection to the
Internet.The interface
business GmbH, Dresden has been patiently
supporting &a.joerg; who has often preferred FreeBSD
work over paywork, and used to fall back to their (quite
expensive) EUnet Internet connection whenever his
private connection became too slow or flakey to work
with it...Berkeley Software
Design, Inc. has contributed their DOS
emulator code to the remaining BSD world, which is used
in the dosemu command.Derived Software ContributorsThis software was originally derived from William F. Jolitz's
386BSD release 0.1, though almost none of the original 386BSD
specific code remains. This software has been essentially
re-implemented from the 4.4BSD-Lite release provided by the Computer
Science Research Group (CSRG) at the University of California,
Berkeley and associated academic contributors.There are also portions of NetBSD and OpenBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAda T Lim ada@bsd.orgAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian T. Filipi-Martin atf3r@agate.cs.virginia.eduAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker A.C.P.M.Kalker@student.utwente.nlAlan Cox alc@cs.rice.eduAmancio Hasty ahasty@freebsd.orgAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndrew Gallatin gallatin@cs.duke.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew McRae amcrae@cisco.comAndrew Moore alm@FreeBSD.orgAndrew Stevenson andrew@ugh.net.auAndrew V. Stesin stesin@elvisti.kiev.uaAndrey Zakhvatov andy@icc.surw.chel.suAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.com
-
+
+
+ Anton Berezin tobez@plab.ku.dk
+
+
Ari Suutari ari@suutari.iki.fiBen Hutchinson benhutch@xfiles.org.ukBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBrandon Gillespie brandon@roguetrader.com&a.wlloyd;Bob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Taylor brett@peloton.physics.montana.eduBrian Clapper bmc@willscreek.com
-
+
+
+ Brian F. Feldman green@unixhelp.org
+
+
Brian Handy handy@lambic.space.lockheed.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce Gingery bgingery@gtcs.comBruce Mah bmah@ca.sandia.govCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCharles Hannum mycroft@ai.mit.eduCharles Mott cmott@srv.netChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChris Dabrowski chris@vader.orgChris G. Demetriou cgd@postgres.berkeley.eduChris Shenton cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristoph Robitschko chmr@edvz.tu-graz.ac.atChristopher T. Johnson
cjohnson@neunacht.netgsi.comChoi Jun Ho junker@jazz.snu.ac.krChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGConrad Sabatier conrads@neosoft.comCornelis van der Laan nils@guru.ims.uni-stuttgart.deCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comDai Ishijima ishijima@tri.pref.osaka.jpDan Cross tenser@spitfire.ecsel.psu.eduDaniel Baker dbaker@crash.ops.neosoft.comDaniel M. Eischen deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDanny J. Zerkel dzerkel@feephi.phofarm.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Edmondson davided@sco.comDave Rivers rivers@ponds.uucpDavid A. Bader dbader@umiacs.umd.eduDavid Dawes dawes@physics.su.OZ.AUDavid Holloway daveh@gwythaint.tamis.comDavid Leonard d@scry.dstc.edu.auDean Huxley dean@fsa.ca
-
+
+
+ Dima Sivachenko demon@gpad.ac.ru
+
+
Dirk Froemberg dirk@hal.in-berlin.deDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Yuniskis dgy@rtd.comDonald Maddox dmaddox@scsn.netDoug Ambrisko ambrisko@ambrisko.roble.comDouglas Carmichael dcarmich@mcs.comEckart “Isegrim” Hofmann
Isegrim@Wunder-Nett.orgEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Chet ejc@bazzle.comEric J. Schwertfeger eric@cybernut.comFrancis M J Hsieh mjhsieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan frankch@waru.life.nthu.edu.twFrank Maclachlan fpm@crash.cts.comFrank Nobis fn@trinity.radio-do.deFrank Volf volf@oasis.IAEhv.nlFUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jpFURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jpGary A. Browning gab10@griffcd.amdahl.comGary Kline kline@thought.orgGerard Roudier groudier@club-internet.frGilad Rom rom_glsa@ein-hashofet.co.ukGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGlenn Johnson gljohns@bellsouth.netGreg Ungerer gerg@stallion.oz.auHans Huebner hans@artcom.deHans Petter Bieker hanspb@persbraten.vgs.noHarlan Stenn Harlan.Stenn@pfcs.comHavard Eidnes Havard.Eidnes@runit.sintef.noHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jp
-
- Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
-
-
Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+
+
Hironori Ikura hikura@kaisei.orgHiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jpHolger Veit Holger.Veit@gmd.deHONDA Yasuhiro honda@kashio.info.mie-u.ac.jpHorance Chou horance@freedom.ie.cycu.edu.twHung-Chi Chu hcchu@r350.ee.ntu.edu.twIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jpIshii MasahiroIseei Suzuki issei@jp.FreeBSD.ORGItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. David Lowe lowe@saturn5.comJ. Han jtc@cygnus.comJ.T. Conklin jtc@cygnus.comJ.T. Lang keith@email.gcn.net.twJames Clark jjc@jclark.comJames da Silva jds@cs.umd.edu et alJanusz Kokot janek@gaja.ipan.lublin.plJason Thorpe thorpej@nas.nasa.govJavier Martin Rueda jmrueda@diatel.upm.esJeff Bartig jeffb@doit.wisc.eduKeff Kletsky Jeff@Wagsky.comJeffrey Wheat jeff@cetlink.netJeremy Lea reg@shale.csir.co.zaJerry Hicks jhicks@glenatl.glenayre.comJian-Da Li jdli@csie.NCTU.edu.twJim Binkley jrb@cs.pdx.eduJim Lowe james@cs.uwm.edu
-
+
+
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld/orgJoao Carlos Mendes Luis jonny@coppe.ufrj.br
+
+ Joe Abley jabley@clear.co.nz
+
+
Joe “Marcus” Clarke
marcus@miami.eduJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoel Sutton sutton@aardvark.apana.org.auJohann Tonsing jtonsing@mikom.csir.co.zaJohn Capo jc@irbs.comJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Perry perry@vishnu.alias.netJohn Polstra jdp@polstra.comJohn Rochester jr@cs.mun.caJohn Saunders john@pacer.nlc.net.auJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJosef Karthauser joe@uk.freebsd.orgJoseph Stein joes@seaport.netJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJulian Assange proff@suburbia.netJulian Jenkins kaveman@magna.com.auJulian Stacey jhs@freebsd.orgJunichi Satoh junichi@jp.freebsd.orgJunya WATANABE junya-w@remus.dti.ne.jpKapil Chowksey kchowksey@hss.hns.comKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKeith Bostic bostic@bostic.comKeith MooreKenneth Monville desmo@bandwidth.orgKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKirk McKusick mckusick@mckusick.comKiroh HARADA kiroh@kh.rim.or.jpKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.su
-
+
+
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+
+
Kurt Olsen kurto@tiny.mcs.usu.eduLars Köller Lars.Koeller@Uni-Bielefeld.DELian Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twuLucas James Lucas.James@ldjpc.apana.org.auLuigi Rizzo luigi@iet.unipi.it
-
+
+
+ Malte Lance malte.lance@gmx.net
+
+
Makoto MATSUSHITA matusita@jp.freebsd.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jp
+
+
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ Manu Iyengar iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMario Sergio Fujikawa Ferreira lioux@gns.com.brMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin BirgmeierMartti Kuparinen erakupa@kk.etx.ericsson.seMasachika ISHIZUKA ishizuka@isis.min.ntt.jpMasanori Kiriake seiken@ncs.co.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas thomas@lkg.dec.comMatt White mwhite+@CMU.EDUMatthew N. Dodd winter@jurai.netMatthew Stein matt@bdd.netMaurice Castro maurice@planet.serc.rmit.edu.auMichael Butschky butsch@computi.erols.comMichael Elbel me@FreeBSD.ORGMichael Searle searle@longacre.demon.co.ukMiguel Angel Sagreras msagre@cactus.fi.uba.arMikael Hybsch micke@dynas.seMikhail Teterin mi@aldan.ziplink.netMike McGaughey mmcg@cs.monash.edu.auMike Peck mike@binghamton.eduMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMITA Yoshio mita@jp.FreeBSD.ORGMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMotoyuki Kasahara m-hasahr@sra.co.jp
+
+
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.comNAKAMURA Kazushi nkazushi@highway.or.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNIIMI Satoshi sa2c@and.or.jpNick Sayer nsayer@quack.kfu.comNicolas Souchu Nicolas.Souchu@prism.uvsq.frNisha Talagala nisha@cs.berkeley.eduNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
+
+
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+
+
Noritaka Ishizumi graphite@jp.FreeBSD.ORGOliver Breuninger ob@seicom.NETOliver Fromme oliver.fromme@heim3.tu-clausthal.deOliver Laumann net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.com
-
+
+
+ Palle Girgensohn girgen@partitur.se
+
+
Paul Fox pgf@foxharp.boston.ma.usPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaulo Menezes paulo@isr.uc.ptPaul T. Root proot@horton.iaces.comPedro Giffuni giffunip@asme.orgPedro A M Vazquez vazquez@IQM.Unicamp.BRPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Stubbs PETERS@staidan.qld.edu.auPierre Beyssac bp@fasterix.freenix.orgPhil Maker pjm@cs.ntu.edu.auR. Kym HorsellRandall Hopper rhh@stealth.ct.picker.comRicardas Cepas rch@richard.eu.orgRichard Hwang rhwang@bigpanda.comRichard. M. Neswold rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Wiwatowski rjwiwat@adelaide.on.netRob Mallory rmallory@csusb.eduRob Shady rls@id.netRob Snow rsnow@txdirect.netRobert Sanders rsanders@mindspring.comRobert Withrow witr@rwwa.comRonald Kuehn kuehn@rz.tu-clausthal.deRoland Jesse jesse@cs.uni-magdeburg.deRuslan Shevchenko rssh@cki.ipri.kiev.uaSURANYI Peter suranyip@jks.is.tsukuba.ac.jpSamuel Lam skl@ScalableNetwork.comSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+
+ Satsuki FUJISHIMA k5@respo.or.jp
+
+
Scot W. Hetzel hetzels@westbend.netScott Blachowicz scott.blachowicz@seaslug.orgScott A. Kenney saken@rmta.ml.orgSeigou TANIMURA
tanimura@naklab.dnj.ynu.ac.jp
-
- Seiichirou Hiraoka flathill@flathill.gr.jp
-
-
Serge Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSheldon Hearn axl@iafrica.comShigeyuki FUKUSHIMA
shige@kuis.kyoto-u.ac.jpSimon Marlow simonm@dcs.gla.ac.ukSlaven Rezic (Tomic) eserte@cs.tu-berlin.deSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan “Sec” Zehl sec@42.orgStephane Legrand stephane@lituus.frStephen Farrell stephen@farrell.orgStephen J. Roznowski sjr@home.netSteve Gerakines steve2@genesis.tiac.netSteven G. Kargl
kargl@troutmask.apl.washington.eduStephen H. Samorodin samorodi@NUXU.comStuart Henderson
stuart@internationalschool.co.uk
+
+
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeu NAIKI naiki@bfd.es.hokudai.ac.jpTed Faber faber@ISI.EDUTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo Deraadt deraadt@fsa.caThomas König Thomas.Koenig@ciw.uni-karlsruhe.deÞórður Ívarsson totii@est.isTim Kientzle kientzle@netcom.comTim Wilkinson tim@sarc.city.ac.uk
+
+ Tom Hukins tom@eborcom.com
+
+
Tom Jobbins tom@tom.tjTom Samplonius tom@misery.sdf.comTorbjorn Granlund tege@matematik.su.seToshihiro Kanda candy@fct.kgc.co.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpTrefor S. trefor@flevel.co.uk
-
+
+
+ Vadim Chekan vadim@gc.lviv.ua
+
+
Ville Eerola ve@sci.fiVladimir Kushnir kushn@mail.kar.netWerner Griessl werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWilko Bulte wilko@yedi.iaf.nlWolfgang Stanglmeier wolf@kintaro.cologne.deWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshiro Mihira sanpei@yy.cs.keio.ac.jp
- Yukihiro Nakai nakai@technologist.com
+ Yukihiro Nakai nakai@iname.comYusuke Nawano azuki@azkey.orgYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nl386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse lohse@tech7.informatik.uni-hamburg.deJörg Wunsch joerg_wunsch@uriah.heep.sax.deJohn Dyson formerly
dyson@ref.tfs.comJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@freebsd.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.ORGRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
index 93ceb6062b..f29687c694 100644
--- a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
@@ -1,2497 +1,2528 @@
The Cutting Edge: FreeBSD-current and FreeBSD-stableFreeBSD is under constant development between releases. For
people who want to be on the cutting edge, there are several easy
mechanisms for keeping your system in sync with the latest
developments. Be warned: the cutting edge is not for everyone! This
chapter will help you decide if you want to track the development
system, or stick with one of the released versions.Staying Current with FreeBSDContributed by &a.jkh;.What is FreeBSD-current?FreeBSD-current is, quite literally, nothing more than a daily
snapshot of the working sources for FreeBSD. These include work
in progress, experimental changes and transitional mechanisms that
may or may not be present in the next official release of the
software. While many of us compile almost daily from
FreeBSD-current sources, there are periods of time when the
sources are literally un-compilable. These problems are generally
resolved as expeditiously as possible, but whether or not
FreeBSD-current sources bring disaster or greatly desired
functionality can literally be a matter of which part of any given
24 hour period you grabbed them in!Who needs FreeBSD-current?FreeBSD-current is made generally available for 3 primary
interest groups:Members of the FreeBSD group who are actively working
on some part of the source tree and for whom keeping
“current” is an absolute requirement.Members of the FreeBSD group who are active testers,
willing to spend time working through problems in order to
ensure that FreeBSD-current remains as sane as possible.
These are also people who wish to make topical suggestions
on changes and the general direction of FreeBSD.Peripheral members of the FreeBSD (or some other)
group who merely wish to keep an eye on things and use the
current sources for reference purposes (e.g. for
reading, not running). These people
also make the occasional comment or contribute code.What is FreeBSD-current not?A fast-track to getting pre-release bits because you
heard there is some cool new feature in there and you want
to be the first on your block to have it.A quick way of getting bug fixes.In any way “officially supported” by us. We do our
best to help people genuinely in one of the 3 “legitimate”
FreeBSD-current categories, but we simply do not
have the time to provide tech support for it.
This is not because we are mean and nasty people who do not
like helping people out (we would not even be doing FreeBSD
if we were), it is literally because we cannot answer 400
messages a day and actually work on
FreeBSD! I am sure that, if given the choice between having
us answer lots of questions or continuing to improve
FreeBSD, most of you would vote for us improving it.Using FreeBSD-currentJoin the &a.current; and the &a.cvsall; . This is not
just a good idea, it is essential. If
you are not on the FreeBSD-current
- mailing list you will not see the comments that people are
+ mailing list, you will not see the comments that people are
making about the current state of the system and thus will
probably end up stumbling over a lot of problems that others
have already found and solved. Even more importantly, you
- will miss out on potentially critical information (e.g.
- “Yo, Everybody! Before you rebuild
- /usr/src, you must
- rebuild the kernel or your system will crash horribly!”).
- The cvs-all mailing list will allow you
+ will miss out on important bulletins which may be critical
+ to your system's continued health.
+
+ The cvs-all mailing list will allow you
to see the commit log entry for each change as it is made
along with any pertinent information on possible
- side-effects. To join these lists, send mail to
+ side-effects.
+
+ To join these lists, send mail to
&a.majordomo; and specify:
subscribe freebsd-current
subscribe cvs-all
in the
body of your message. Optionally, you can also say help
and Majordomo will send you full help on how to subscribe
and unsubscribe to the various other mailing lists we
support.Grab the sources from ftp.FreeBSD.ORG. You can do
this in three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile">this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
+
+
+ &prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgz
+
+
+
Use ftp. The source tree for FreeBSD-current is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current We also use wu-ftpd which allows compressed/tar'd grabbing of whole trees. e.g. you see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the whole directory for you as a compressed tar file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.
-
-
-
+
If you are grabbing the sources to run, and not just
look at, then grab all of current, not
just selected portions. The reason for this is that various
parts of the source depend on updates elsewhere, and trying
to compile just a subset is almost guaranteed to get you
into trouble.
-
-
-
+
Before compiling current, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.current; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
- towards the next release.
+ towards the next release.
Be active! If you are running FreeBSD-current, we
want to know what you have to say about it, especially if
you have suggestions for enhancements or bug fixes.
Suggestions with accompanying code are received most
enthusiastically!Staying Stable with FreeBSDContributed by &a.jkh;.What is FreeBSD-stable?FreeBSD-stable is our development branch for a more low-key
and conservative set of changes intended for our next mainstream
release. Changes of an experimental or untested nature do not go
into this branch (see FreeBSD-current).Who needs FreeBSD-stable?If you are a commercial user or someone who puts maximum
stability of their FreeBSD system before all other concerns, you
should consider tracking stable. This is
especially true if you have installed the most recent release
(&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release.The stable tree endeavors, above all,
to be fully compilable and stable at all times, but we do
occasionally make mistakes (these are still active sources with
quickly-transmitted updates, after all). We also do our best to
thoroughly test fixes in current before
bringing them into stable, but sometimes
our tests fail to catch every case. If something breaks for you
in stable, please let us know
immediately! (see next section).Using FreeBSD-stableJoin the &a.stable; . This will keep you informed of
build-dependencies that may appear in
stable or any other issues requiring
special attention. Developers will also make announcements
in this mailing list when they are contemplating some
controversial fix or update, giving the users a chance to
respond if they have any issues to raise concerning the
- proposed change. To join this list, send mail to
- &a.majordomo; and say:
+ proposed change.
+
+ The cvs-all mailing list will allow you
+ to see the commit log entry for each change as it is made
+ along with any pertinent information on possible
+ side-effects.
+
+ To join these lists, send mail to
+ &a.majordomo; and specify:
-subscribe freebsd-stable In the body of your
- message. Optionally, you can also say help and Majordomo
- will send you full help on how to subscribe and unsubscribe
- to the various other mailing lists we support.
+subscribe freebsd-stable
+subscribe cvs-all
+
+ in the
+ body of your message. Optionally, you can also say help
+ and Majordomo will send you full help on how to subscribe
+ and unsubscribe to the various other mailing lists we
+ support.
If you are installing a new system and want it to be as stable
as possible, you can simply grab the latest dated branch snapshot
from ftp://releng22.freebsd.org/pub/FreeBSD/ and install it like any other release.If you are already running a previous release of 2.2 and wish
to upgrade via sources then you can easily do so from ftp.FreeBSD.ORG. This can be done in one of
three ways:Use the CTM
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.Use the cvsup
program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type;&prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupit.tgzUse ftp. The source tree for FreeBSD-stable is
always “exported” on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stableWe also use wu-ftpd which allows
compressed/tar'd grabbing of whole trees. e.g. you
see:usr.bin/lexYou can do:
ftp>cd usr.binftp>get lex.tar.Z
and it will get the
whole directory for you as a compressed tar
file.Essentially, if you need rapid on-demand access to the
source and communications bandwidth is not a consideration,
use cvsup or ftp. Otherwise, use CTM.Before compiling stable, read the Makefile in
/usr/src carefully. You should at
least run a make world the first time
through as part of the upgrading process. Reading the
&a.stable; will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move
towards the next release.Synchronizing Source Trees over the InternetContributed by &a.jkh;.There are various ways of using an Internet (or email)
connection to stay up-to-date with any given area of the FreeBSD
project sources, or all areas, depending on what interests you. The
primary services we offer are Anonymous
CVS, CVSup, and
CTM.Anonymous CVS and CVSup use the
pull model of updating sources. In the case of
CVSup the user (or a cron
script) invokes the cvsup program, and
it interacts with a cvsupd server
somewhere to bring your files up to date. The updates you receive
are up-to-the-minute and you get them when, and only when, you want
them. You can easily restrict your updates to the specific files or
directories that are of interest to you. Updates are generated on
the fly by the server, according to what you have and what you want
to have. Anonymous CVS is quite a bit more simplistic
than CVSup in that it's just an extension to
CVS which allows it to pull changes
directly from a remote CVS
repository. CVSup can do this far more
efficiently, but Anonymous CVS is easier to
use.CTM, on the other hand, does not
interactively compare the sources you have with those on the master
archive or otherwise pull them across.. Instead, a script which identifies changes in files since
its previous run is executed several times a day on the master CTM
machine,
any detected changes being compressed, stamped with a
sequence-number and encoded for transmission over email (in printable
ASCII only). Once received, these “CTM deltas” can then be handed
to the ctm_rmail1 utility which will automatically decode, verify
and apply the changes to the user's copy of the sources. This
process is far more efficient than CVSup, and places less strain on
our server resources since it is a push rather
than a pull model.There are other trade-offs, of course. If you inadvertently
wipe out portions of your archive, CVSup will detect and rebuild the
damaged portions for you. CTM won't do this, and if you wipe some
portion of your source tree out (and don't have it backed up) then
you will have to start from scratch (from the most recent CVS “base
delta”) and rebuild it all with CTM or, with anoncvs, simply
delete the bad bits and resync.For more information on Anonymous CVS, CTM, and CVSup, please see one of the
following sections:Anonymous CVSContributed by &a.jkh;IntroductionAnonymous CVS (or, as it is otherwise known,
anoncvs) is a feature provided by the CVS
utilities bundled with FreeBSD for synchronizing with a remote CVS
repository. Among other things, it allows users of FreeBSD to
perform, with no special privileges, read-only CVS operations
against one of the FreeBSD project's official anoncvs servers. To
use it, one simply sets the CVSROOT environment
variable to point at the appropriate anoncvs server and then uses
the cvs1 command to access it like any local
repository.While it can also be said that the CVSup and anoncvs
services both perform essentially the same function, there are
various trade-offs which can influence the user's choice of
synchronization methods. In a nutshell,
CVSup is much more efficient in its
usage of network resources and is by far the most technically
sophisticated of the two, but at a price. To use
CVSup, a special client must first be
installed and configured before any bits can be grabbed, and then
only in the fairly large chunks which
CVSup calls
collections.Anoncvs, by contrast, can be used
to examine anything from an individual file to a specific program
(like ls or grep) by
referencing the CVS module name. Of course,
anoncvs is also only good for read-only
operations on the CVS repository, so if it's your intention to
support local development in one repository shared with the
FreeBSD project bits then CVSup is
really your only option.Using Anonymous CVSConfiguring cvs1 to use an Anonymous CVS repository is a simple
matter of setting the CVSROOT environment variable
to point to one of the FreeBSD project's
anoncvs servers. At the time of this writing,
the following servers are available:USA:
anoncvs@anoncvs.freebsd.org:/cvsSince CVS allows one to “check out” virtually any
version of the FreeBSD sources that ever existed (or, in some
cases, will exist :), you need to be familiar with
the revision () flag to cvs1 and what some of the permissible values for it in
the FreeBSD Project repository are.There are two kinds of tags, revision tags and branch tags. A
revision tag refers to a specific revision. Its meaning stays the
same from day to day. A branch tag, on the other hand, refers to
the latest revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific revision,
it may mean something different tomorrow than it means
today.Here are the branch tags that users might be interested
in:HEADSymbolic name for the main line, or FreeBSD-current.
Also the default when no revision is
specified.
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
RELENG_2_2The line of development for FreeBSD-2.2.x, also known as
- FreeBSD-stable. Not valid for the ports collection.
+ 2.2-stable. Not valid for the ports collection.
RELENG_2_1_0The line of development for FreeBSD-2.1.x - this branch
is largely obsolete. Not valid for the ports
collection.Here are the revision tags that users might be interested
in:RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports
collection.RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports
collection.RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports
collection.RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports
collection.RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports
collection.RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports
collection.RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports
collection.RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports
collection.RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports
collection.RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports
collection.When you specify a branch tag, you normally receive the latest
versions of the files on that line of development. If you wish to
receive some past version, you can do so by specifying a date with
the flag. See the cvs1 man page for more details.ExamplesWhile it really is recommended that you read the manual page
for cvs1 thoroughly before doing
anything, here are some quick examples which essentially show how
to use Anonymous CVS:Checking out something from -current (ls1) and deleting it
again:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co ls
&prompt.user; cvs release -d lsChecking out the version of ls(1) in the 2.2-stable
branch:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co -rRELENG_2_2 ls
&prompt.user; cvs release -d lsCreating a list of changes (as unidiffs) to ls1 between FreeBSD 2.2.2
and FreeBSD 2.2.6:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE lsFinding out what other module names can be used:
&prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs
&prompt.user; cvs co modules
&prompt.user; more modules/modules
&prompt.user; cvs release -d modulesOther ResourcesThe following additional resources may be helpful in learning
CVS:CVS Tutorial from Cal Poly.Cyclic
Software, commercial maintainers of CVS.CVSWeb
is the FreeBSD Project web interface for CVS.CTMContributed by &a.phk;. Updated
19-October-1997.CTM is a method for keeping a remote
directory tree in sync with a central one. It has been developed
for usage with FreeBSD's source trees, though other people may
find it useful for other purposes as time goes by. Little, if
any, documentation currently exists at this time on the process of
creating deltas, so talk to &a.phk; for more information should
you wish to use CTM for other things.Why should I use CTM?CTM will give you a local copy of the
FreeBSD source trees. There are a number of “flavors” of the
tree available. Whether you wish to track the entire cvs tree or
just one of the branches, CTM can provide you
the information. If you are an active developer on FreeBSD, but
have lousy or non-existent TCP/IP connectivity, or simply wish
to have the changes automatically sent to you,
CTM was made for you. You will need to obtain
up to three deltas per day for the most active branches.
However, you should consider having them sent by automatic
email. The sizes of the updates are always kept as small as
possible. This is typically less than 5K, with an occasional
(one in ten) being 10-50K and every now and then a biggie of
100K+ or more coming around.You will also need to make yourself aware of the various
caveats related to working directly from the development
sources rather than a pre-packaged release. This is particularly
true if you choose the “current” sources. It is recommended
that you read Staying current
with
FreeBSD.What do I need to use CTM?You will need two things: The CTM
program and the initial deltas to feed it (to get up to
“current” levels).The CTM program has been part of FreeBSD
ever since version 2.0 was released, and lives in
/usr/src/usr.sbin/CTM if
you have a copy of the source online.If you are running a pre-2.0 version of FreeBSD, you can
fetch the current CTM sources directly
from:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctmThe “deltas” you feed CTM can be had
two ways, FTP or e-mail. If you have general FTP access to the
Internet then the following FTP sites support access to
CTM:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTMor see section mirrors.FTP the relevant directory and fetch the
README file, starting from there.If you may wish to get your deltas via email:Send email to &a.majordomo; to subscribe to one of the
CTM distribution lists. “ctm-cvs-cur”
supports the entire cvs tree. “ctm-src-cur” supports the head
of the development branch. “ctm-src-2_2” supports the 2.2
release branch, etc. (If you do not know how to subscribe
yourself using majordomo, send a message first containing the
word help — it will send you back usage
instructions.)When you begin receiving your CTM updates
in the mail, you may use the ctm_rmail program
to unpack and apply them. You can actually use the
ctm_rmail program directly from a entry in
/etc/aliases if you want to have the
process run in a fully automated fashion. Check the
ctm_rmail man page for more details.No matter what method you use to get the
CTM deltas, you should subscribe to the
ctm-announce@FreeBSD.ORG mailing list. In the
future, this will be the only place where announcements
concerning the operations of the CTM system
will be posted. Send an email to &a.majordomo; with a single
line of subscribe
ctm-announce to get added to the list.Starting off with CTM for the first
timeBefore you can start using CTM deltas,
you will need to get a to a starting point for the deltas
produced subsequently to it.First you should determine what you already have. Everyone
can start from an “empty” directory. You must use an
initial “Empty&rdquo delta to start off your
CTM supported tree. At some point it is
intended that one of these “started” deltas be
distributed on the CD for your convenience. This does not
currently happen however.You can recognize
However, since the trees
are many tens of megabytes, you should prefer to start from
something already at hand. If you have a RELEASE CD, you can
copy or extract an initial source from it. This will save a
significant transfer of data.You can recognize these “starter” deltas by the
X appended to the number
(src-cur.3210XEmpty.gz for instance). The
designation following the X
corresponds to the origin of your initial “seed”. Empty is
an empty directory. As a rule a base transition from
Empty is produced
every 100 deltas. By the way, they are large! 25 to 30
Megabytes of gzip'ed data is
common for the XEmpty deltas.Once you've picked a base delta to start from, you will also
need all deltas with higher numbers following it.Using CTM in your daily lifeTo apply the deltas, simply say:&prompt.root; cd /where/ever/you/want/the/stuff
&prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.*CTM understands deltas which have been
put through gzip, so you do not
need to gunzip them first, this saves disk space.Unless it feels very secure about the entire process,
CTM will not touch your tree. To verify a
delta you can also use the flag and
CTM will not actually touch your tree; it
will merely verify the integrity of the delta and see if it
would apply cleanly to your current tree.There are other options to CTM as well,
see the manual pages or look in the sources for more
information.I would also be very happy if somebody could help with the
“user interface” portions, as I have realized that I cannot
make up my mind on what options should do what, how and
when...That's really all there is to it. Every time you get a new
delta, just run it through CTM to keep your
sources up to date.Do not remove the deltas if they are hard to download again.
You just might want to keep them around in case something bad
happens. Even if you only have floppy disks, consider using
fdwrite to make a copy.Keeping your local changesAs a developer one would like to experiment with and change
files in the source tree. CTM supports local modifications in a
limited way: before checking for the presence of a file
foo, it first looks for
foo.ctm. If this file exists, CTM will
operate on it instead of foo.This behaviour gives us a simple way to maintain local
changes: simply copy the files you plan to modify to the
corresponding file names with a .ctm
suffix. Then you can freely hack the code, while CTM keeps the
.ctm file up-to-date.Other interesting CTM optionsFinding out exactly what would be touched by an
updateYou can determine the list of changes that CTM will make
on your source repository using the
option to CTM.This is useful if you would like to keep logs of the
changes, pre- or post- process the modified files in any
manner, or just are feeling a tad paranoid :-).Making backups before updatingSometimes you may want to backup all the files that would
be changed by a CTM update.Specifying the option
causes CTM to backup all files that would be touched by a
given CTM delta to backup-file.Restricting the files touched by an updateSometimes you would be interested in restricting the scope
of a given CTM update, or may be interested in extracting just
a few files from a sequence of deltas.You can control the list of files that CTM would operate
on by specifying filtering regular expressions using the
and
options.For example, to extract an up-to-date copy of
lib/libc/Makefile from your collection of
saved CTM deltas, run the commands:&prompt.root; cd /where/ever/you/want/to/extract/it/
&prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.*For every file specified in a CTM delta, the
and options
are applied in the order given on the command line. The file
is processed by CTM only if it is marked as eligible after all
the and
options are applied to it.Future plans for CTMTons of them:Use some kind of authentication into the CTM system,
so as to allow detection of spoofed CTM updates.Clean up the options to CTM, they
became confusing and counter intuitive.The bad news is that I am very busy, so any help in doing
this will be most welcome. And do not forget to tell me what
you want also...Miscellaneous stuffAll the “DES infected” (e.g. export controlled) source is
not included. You will get the “international” version only.
If sufficient interest appears, we will set up a sec-cur sequence too. There is a
sequence of deltas for the ports
collection too, but interest has not been all that high yet.
Tell me if you want an email list for that too and we will
consider setting it up.Thanks!&a.bde;for his pointed pen and invaluable comments.&a.sos;for patience.Stephen McKaywrote ctm_[rs]mail,
much appreciated.&a.jkh;for being so stubborn that I had to make it
better.All the usersI hope you like it...CVSupContributed by &a.jdp;.IntroductionCVSup is a software package for distributing and updating
source trees from a master CVS repository on a remote server
host. The FreeBSD sources are maintained in a CVS repository on
a central development machine in California. With CVSup,
FreeBSD users can easily keep their own source trees up to
date.CVSup uses the so-called pull model of
updating. Under the pull model, each client asks the server for
updates, if and when they are wanted. The server waits
passively for update requests from its clients. Thus all
updates are instigated by the client. The server never sends
unsolicited updates. Users must either run the CVSup client
manually to get an update, or they must set up a cron job to run
it automatically on a regular basis.The term CVSup, capitalized just so, refers to the entire
software package. Its main components are the client cvsup
which runs on each user's machine, and the server cvsupd which
runs at each of the FreeBSD mirror sites.As you read the FreeBSD documentation and mailing lists, you
may see references to sup. Sup was the
predecessor of CVSup, and it served a similar purpose. CVSup is
in used in much the same way as sup and, in fact, uses
configuration files which are backward-compatible with sup's.
Sup is no longer used in the FreeBSD project, because CVSup is
both faster and more flexible.InstallationThe easiest way to install CVSup if you are running FreeBSD
2.2 or later is to use either the port from the FreeBSD ports collection or the corresponding binary package, depending on whether you prefer to roll your own or not.If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately
cannot use the binary package versions due to the fact that it
requires a version of the C library that does not yet exist in
FreeBSD-2.1.{6,7}. You can easily use the port, however, just as with FreeBSD 2.2. Simply unpack the tar file, cd to the cvsup subdirectory and type make install.Because CVSup is written in Modula-3, both the package and the port require that the Modula-3 runtime libraries be installed. These are available as the lang/modula-3-lib port and the lang/modula-3-lib-3.6 package. If you follow the same directions as for cvsup, these libraries will be compiled and/or installed automatically when you install the CVSup port or package.The Modula-3 libraries are rather large, and fetching and
compiling them is not an instantaneous process. For that
reason, a third option is provided. You can get
statically linked FreeBSD executables for
CVSup from either the USA distribution site:ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup-bin-15.4.2.tar.gz (client including GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.4.2.tar.gz (client without GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupd-bin-15.4.2.tar.gz (server).as well as from the many FreeBSD FTP mirror sites around the
world.ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-15.3.tar.gz (client including GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.3.tar.gz (client without GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-15.3.tar.gz (server).Most users will need only the client. These executables are
entirely self-contained, and they will run on any version of
FreeBSD from FreeBSD-2.1.0 to FreeBSD-current.In summary, your options for installing CVSup are:FreeBSD-2.2 or later: static binary, port,
or packageFreeBSD-2.1.6, 2.1.7: static binary or
portFreeBSD-2.1.5 or earlier: static binaryConfigurationCVSup's operation is controlled by a configuration file
called the supfile. Beginning with
FreeBSD-2.2, there are some sample supfiles
in the directory /usr/share/examples/cvsup. These examples are also available from ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ if you are on a pre-2.2 system.The information in a supfile answers
the following questions for cvsup:Which files
do you want to receive?Which
versions of them do you want?Where do you
want to get them from?Where do you
want to put them on your own machine?Where do
you want to put your status files?In the following sections, we will construct a typical
supfile by answering each of these
questions in turn. First, we describe the overall structure of
a supfile.A supfile is a text file. Comments
begin with # and extend to the end of the line. Lines that
are blank and lines that contain only comments are
ignored.Each remaining line describes a set of files that the user
wishes to receive. The line begins with the name of a
“collection”, a logical grouping of files defined by the server.
The name of the collection tells the server which files you
want. After the collection name come zero or more fields,
separated by white space. These fields answer the questions
listed above. There are two types of fields: flag fields and
value fields. A flag field consists of a keyword standing
alone, e.g., delete or compress. A value field also begins
with a keyword, but the keyword is followed without intervening
white space by = and a second word. For example,
release=cvs is a value field.A supfile typically specifies more than
one collection to receive. One way to structure a
supfile is to specify all of the relevant
fields explicitly for each collection. However, that tends to
make the supfile lines quite long, and it
is inconvenient because most fields are the same for all of the
collections in a supfile. CVSup provides a
defaulting mechanism to avoid these problems. Lines beginning
with the special pseudo-collection name *default can be used
to set flags and values which will be used as defaults for the
subsequent collections in the supfile. A
default value can be overridden for an individual collection, by
specifying a different value with the collection itself.
Defaults can also be changed or augmented in mid-supfile by
additional *default lines.With this background, we will now proceed to construct a
supfile for receiving and updating the main
source tree of FreeBSD-current.Which files do you want to receive?The files available via CVSup are organized into named
groups called “collections”. The collections that are
available are described here. In this example, we wish to receive the
entire main source tree for the FreeBSD system. There is
a single large collection src-all which will give us all
of that, except the export-controlled cryptography
support. Let us assume for this example that we are in
the USA or Canada. Then we can get the cryptography code
with one additional collection, cvs-crypto. As a first
step toward constructing our supfile,
we simply list these collections, one per line:
src-all
cvs-cryptoWhich version(s) of them do you want?With CVSup, you can receive virtually any version of
the sources that ever existed. That is possible because
the cvsupd server works directly from the CVS repository,
which contains all of the versions. You specify which one
of them you want using the tag= and value
fields.Be very
careful to specify any tag= fields correctly. Some tags
are valid only for certain collections of files. If you
specify an incorrect or misspelled tag, CVSup will delete
files which you probably do not want deleted. In
particular, use only
tag=. for the ports-*
collections.The tag= field names a symbolic tag in the
repository. There are two kinds of tags, revision tags
and branch tags. A revision tag refers to a specific
revision. Its meaning stays the same from day to day. A
branch tag, on the other hand, refers to the latest
revision on a given line of development, at any given
time. Because a branch tag does not refer to a specific
revision, it may mean something different tomorrow than it
means today.Here are the branch tags that users might be
interested in:tag=.The main line of development, also known as
FreeBSD-current.The . is not punctuation; it is the name
of the tag. Valid for all collections.
-
- tag=RELENG_2_2
-
-
- The line of development for FreeBSD-2.2.x,
- also known as FreeBSD-stable. Not valid for the
- ports-* collections.
-
-
-
-
+
+
+ RELENG_3
+
+
+ The line of development for FreeBSD-3.x, also known as
+ FreeBSD-stable. Not valid for the ports collection.
+
+
+
+
+ RELENG_2_2
+
+
+ The line of development for FreeBSD-2.2.x, also known as
+ 2.2-stable. Not valid for the ports collection.
+
+
+
tag=RELENG_2_1_0The line of development for FreeBSD-2.1.x -
this branch is largely obsolete. Not valid for the
ports-* collections.Here are the revision tags that users might be
interested in:tag=RELENG_3_0_0_RELEASEFreeBSD-3.0. Not valid for the ports-*
collections.tag=RELENG_2_2_7_RELEASEFreeBSD-2.2.7. Not valid for the ports-*
collections.tag=RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports-*
collections.tag=RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports-*
collections.tag=RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports-*
collections.tag=RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports-*
collections.tag=RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports-*
collections.tag=RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports-*
collections.tag=RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports-*
collections.tag=RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports-*
collections.tag=RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports-*
collections.tag=RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports-*
collections.Be very
careful to type the tag name exactly as shown. CVSup
cannot distinguish between valid and invalid tags. If you
misspell the tag, CVSup will behave as though you had
specified a valid tag which happens to refer to no files
at all. It will delete your existing sources in that
case.When you specify a branch tag, you normally receive
the latest versions of the files on that line of
development. If you wish to receive some past version,
you can do so by specifying a date with the value
field. The cvsup1 manual page explains how to do
that.For our example, we wish to receive FreeBSD-current.
We add this line at the beginning of our
supfile:
*default tag=.There is an important special case that comes into
play if you specify neither a tag=
field nor a date=
field. In that case, you receive the actual RCS files
directly from the server's CVS repository, rather than
receiving a particular version. Developers generally
prefer this mode of operation. By maintaining a copy of
the repository itself on their systems, they gain the
ability to browse the revision histories and examine past
versions of files. This gain is achieved at a large cost
in terms of disk space, however.Where do you want to get them from?We use the host= field to tell cvsup where to obtain
its updates. Any of the CVSup
mirror sites will do, though you should try to select
one that's near to you. In this example, we'll use the
primary FreeBSD distribution site,
cvsup.FreeBSD.org:
*default host=cvsup.FreeBSD.orgOn any particular run of cvsup, you can override this
setting on the command line, with .Where do you want to put them on your own
machine?The prefix= field tells cvsup where to put the files
it receives. In this example, we will put the source files
directly into our main source tree, /usr/src. The src
directory is already implicit in the collections we have
chosen to receive, so this is the correct
specification:
*default prefix=/usrWhere should cvsup maintain its status files?The cvsup client maintains certain status files in
what is called the “base” directory. These files help
CVSup to work more efficiently, by keeping track of which
updates you have already received. We will use the
standard base directory, /usr/local/etc/cvsup:
*default base=/usr/local/etc/cvsupThis setting is used by default if it is not specified
in the supfile, so we actually do not
need the above line.If your base directory does not already exist, now
would be a good time to create it. The cvsup client will
refuse to run if the base directory does not exist.Miscellaneous supfile settings:There is one more line of boiler plate that normally
needs to be present in the supfile:
*default release=cvs delete use-rel-suffix compressrelease=cvs indicates that the server should get its
information out of the main FreeBSD CVS repository. This
is virtually always the case, but there are other
possibilities which are beyond the scope of this
discussion.delete gives CVSup permission to delete files. You
should always specify this, so that CVSup can keep your
source tree fully up to date. CVSup is careful to delete
only those files for which it is responsible. Any extra
files you happen to have will be left strictly
alone.use-rel-suffix is ... arcane. If you really want to
know about it, see the cvsup1 manual page. Otherwise,
just specify it and do not worry about it.compress enables the use of gzip-style compression
on the communication channel. If your network link is T1
speed or faster, you probably should not use compression.
Otherwise, it helps substantially.Putting it all together:Here is the entire supfile for
our example:
*default tag=.
*default host=cvsup.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress
src-all
cvs-cryptoRunning CVSupYou are now ready to try an update. The command line for
doing this is quite simple:&prompt.root; cvsup supfilewhere supfile is of course the name of the supfile you
have just created. Assuming you are running under X11, cvsup
will display a GUI window with some buttons to do the usual
things. Press the “go” button, and watch it run.Since you are updating your actual /usr/src tree in this
example, you will need to run the program as root so that cvsup
has the permissions it needs to update your files. Having just
created your configuration file, and having never used this
program before, that might understandably make you nervous.
There is an easy way to do a trial run without touching your
precious files. Just create an empty directory somewhere
convenient, and name it as an extra argument on the command
line:&prompt.root; mkdir /var/tmp/dest
&prompt.root; cvsup supfile /var/tmp/destThe directory you specify will be used as the destination
directory for all file updates. CVSup will examine your usual
files in /usr/src, but it will not modify
or delete any of them. Any file updates will instead land in
/var/tmp/dest/usr/src. CVSup will also
leave its base directory status files untouched when run this
way. The new versions of those files will be written into the
specified directory. As long as you have read access to
/usr/src, you do not even need to be root
to perform this kind of trial run.If you are not running X11 or if you just do not like GUIs,
you should add a couple of options to the command line when you
run cvsup:&prompt.root; cvsup -g -L 2 supfileThe tells cvsup not to use its GUI. This is automatic
if you are not running X11, but otherwise you have to specify
it.The tells cvsup to print out the details of all the
file updates it is doing. There are three levels of verbosity,
from to . The default is 0, which means total
silence except for error messages.There are plenty of other options available. For a brief
list of them, type cvsup -H. For more detailed descriptions,
see the manual page.Once you are satisfied with the way updates are working, you
can arrange for regular runs of cvsup using cron8. Obviously,
you should not let cvsup use its GUI when running it from
cron.CVSup File CollectionsThe file collections available via CVSup are organized
hierarchically. There are a few large collections, and they are
divided into smaller sub-collections. Receiving a large
collection is equivalent to receiving each of its
sub-collections. The hierarchical relationships among
collections are reflected by the use of indentation in the list
below.The most commonly used collections are src-all, cvs-crypto, and ports-all. The other collections are used
only by small groups of people for specialized purposes, and
some mirror sites may not carry all of them.cvs-all
release=cvsThe main FreeBSD CVS repository, excluding the
export-restricted cryptography code.distrib
release=cvsFiles related to the distribution and
mirroring of FreeBSD.doc-all
release=cvsSources for the FreeBSD handbook and other
documentation.ports-all
release=cvsThe FreeBSD ports collection.ports-archivers
release=cvsArchiving tools.ports-astro
release=cvsAstronomical ports.ports-audio
release=cvsSound support.ports-base
release=cvsMiscellaneous files at the top of
/usr/ports.ports-benchmarks
release=cvsBenchmarks.ports-biology
release=cvsBiology.ports-cad
release=cvsComputer aided design tools.ports-chinese
release=cvsChinese language support.ports-comms
release=cvsCommunication software.ports-converters
release=cvscharacter code converters.ports-databases
release=cvsDatabases.ports-deskutils
release=cvsThings that used to be on the desktop before
computers were invented.ports-devel
release=cvsDevelopment utilities.ports-editors
release=cvsEditors.ports-emulators
release=cvsEmulators for other operating
systems.ports-games
release=cvsGames.ports-german
release=cvsGerman language support.ports-graphics
release=cvsGraphics utilities.ports-japanese
release=cvsJapanese language support.ports-korean
release=cvsKorean language support.ports-lang
release=cvsProgramming languages.ports-mail
release=cvsMail software.ports-math
release=cvsNumerical computation
software.ports-mbone
release=cvsMBone applications.ports-misc
release=cvsMiscellaneous utilities.ports-net
release=cvsNetworking software.ports-news
release=cvsUSENET news software.ports-plan9
release=cvsVarious programs from Plan9.ports-print
release=cvsPrinting software.ports-russian
release=cvsRussian language support.ports-security
release=cvsSecurity utilities.ports-shells
release=cvsCommand line shells.ports-sysutils
release=cvsSystem utilities.ports-textproc
release=cvstext processing utilities (does not
include desktop publishing).ports-vietnamese
release=cvsVietnamese language support.ports-www
release=cvsSoftware related to the World Wide
Web.ports-x11
release=cvsPorts to support the X window
system.ports-x11-clocks
release=cvsX11 clocks.ports-x11-fm
release=cvsX11 file managers.ports-x11-fonts
release=cvsX11 fonts and font utilities.ports-x11-toolkits
release=cvsX11 toolkits.ports-x11-wmX11 window managers.src-all
release=cvsThe main FreeBSD sources, excluding the
export-restricted cryptography code.src-base
release=cvsMiscellaneous files at the top of
/usr/src.src-bin
release=cvsUser utilities that may be needed in
single-user mode
(/usr/src/bin).src-contrib
release=cvsUtilities and libraries from outside
the FreeBSD project, used relatively
unmodified
(/usr/src/contrib).src-etc
release=cvsSystem configuration files
(/usr/src/etc).src-games
release=cvsGames
(/usr/src/games).src-gnu
release=cvsUtilities covered by the GNU Public
License
(/usr/src/gnu).src-include
release=cvsHeader files
(/usr/src/include).src-kerberosIV
release=cvsKerberosIV security package
(/usr/src/kerberosIV).src-lib
release=cvsLibraries
(/usr/src/lib).src-libexec
release=cvsSystem programs normally executed by
other programs
(/usr/src/libexec).src-release
release=cvsFiles required to produce a FreeBSD
release
(/usr/src/release).src-sbin
release=cvsSystem utilities for single-user
mode
(/usr/src/sbin).src-share
release=cvsFiles that can be shared across
multiple systems
(/usr/src/share).src-sys
release=cvsThe kernel
(/usr/src/sys).src-tools
release=cvsVarious tools for the maintenance of
FreeBSD
(/usr/src/tools).src-usrbin
release=cvsUser utilities
(/usr/src/usr.bin).src-usrsbin
release=cvsSystem utilities
(/usr/src/usr.sbin).www
release=cvsThe sources for the World Wide Web
data.cvs-crypto
release=cvsThe export-restricted cryptography code.src-crypto
release=cvsExport-restricted utilities and libraries
from outside the FreeBSD project, used
relatively unmodified
(/usr/src/crypto).src-eBones
release=cvsKerberos and DES
(/usr/src/eBones).src-secure
release=cvsDES
(/usr/src/secure).distrib
release=selfThe CVSup server's own configuration files. Used by
CVSup mirror sites.gnats
release=currentThe GNATS bug-tracking database.mail-archive
release=currentFreeBSD mailing list archive.www
release=currentThe installed World Wide Web data. Used by WWW
mirror sites.Announcements, Questions, and Bug ReportsMost FreeBSD-related discussion of CVSup takes place on the
&a.hackers;. New versions of the software are announced there,
as well as on the &a.announce;.Questions and bug reports should be addressed to the author
of the program at cvsup-bugs@polstra.com.Using make world to rebuild your
systemContributed by &a.nik;.Once you have synchronised your local source tree against a
particular version of FreeBSD (stable,
current and so on) you must then use
the source tree to rebuild the system.Currently, the best source of information on how to do that is a
tutorial available from http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html.A successor to this tutorial will be integrated into the
handbook.
diff --git a/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml
index c1fcd45ce2..56e4bc2172 100644
--- a/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml
@@ -1,1143 +1,1289 @@
Resources on the InternetContributed by &a.jkh;.The rapid pace of FreeBSD progress makes print media impractical
as a means of following the latest developments. Electronic resources
are the best, if not often the only, way stay informed of the latest
advances. Since FreeBSD is a volunteer effort, the user community
itself also generally serves as a “technical support department” of
sorts, with electronic mail and USENET news being the most effective
way of reaching that community.The most important points of contact with the FreeBSD user
community are outlined below. If you are aware of other resources not
mentioned here, please send them to the &a.doc;so that they may also
be included.Mailing listsThough many of the FreeBSD development members read USENET, we
cannot always guarantee that we will get to your questions in a
timely fashion (or at all) if you post them only to one of the
comp.unix.bsd.freebsd.* groups. By addressing your questions to the
appropriate mailing list you will reach both us and a concentrated
FreeBSD audience, invariably assuring a better (or at least faster)
response.The charters for the various lists are given at the bottom of
this document. Please read the charter before
joining or sending mail to any list. Most of our list
subscribers now receive many hundreds of FreeBSD related messages
every day, and by setting down charters and rules for proper use we
are striving to keep the signal-to-noise ratio of the lists high.
To do less would see the mailing lists ultimately fail as an
effective communications medium for the project.Archives are kept for all of the mailing lists and can be
searched using the FreeBSD World Wide Web
server. The keyword searchable archive offers an
excellent way of finding answers to frequently asked questions and
should be consulted before posting a question.List summaryGeneral lists: The following are
general lists which anyone is free (and encouraged) to join:ListPurposefreebsd-advocacyFreeBSD Evangelismfreebsd-announceImportant events and project milestonesfreebsd-bugsBug reportsfreebsd-chatNon-technical items related to the FreeBSD
communityfreebsd-currentDiscussion concerning the use of
FreeBSD-current
-
- freebsd-stable
- Discussion concerning the use of
- FreeBSD-stable
-
-
freebsd-ispIssues for Internet Service Providers using
FreeBSDfreebsd-jobsFreeBSD employment and consulting
opportunitiesfreebsd-newbiesNew FreeBSD users activities and discussionsfreebsd-questions
- User questions
+ User questions and technical support
+
+
+ freebsd-stable
+ Discussion concerning the use of
+ FreeBSD-stable
+
+
Technical lists: The following
lists are for technical discussion. You should read the charter
for each list carefully before joining or sending mail to one as
there are firm guidelines for their use and content.ListPurposefreebsd-afsPorting AFS to FreeBSDfreebsd-alphaPorting FreeBSD to the Alphafreebsd-doc
- The FreeBSD Documentation project
+ Creating FreeBSD related documentsfreebsd-databaseDiscussing database use and development under
FreeBSDfreebsd-emulationEmulation of other systems such as
Linux/DOS/Windowsfreebsd-fsFilesystemsfreebsd-hackersGeneral technical discussionfreebsd-hardwareGeneral discussion of hardware for running
FreeBSDfreebsd-isdnISDN developersfreebsd-javaJava developers and people porting JDKs to
FreeBSDfreebsd-mobileDiscussions about mobile computingfreebsd-mozillaPorting mozilla to FreeBSDfreebsd-netNetworking discussion and TCP/IP/source codefreebsd-platformsConcerning ports to non-Intel architecture
platformsfreebsd-portsDiscussion of the ports collectionfreebsd-scsiThe SCSI subsystemfreebsd-securitySecurity issuesfreebsd-smallUsing FreeBSD in embedded applicationsfreebsd-smpDesign discussions for [A]Symmetric
MultiProcessingfreebsd-sparcPorting FreeBSD to Sparc systemsfreebsd-tokenringSupport Token Ring in FreeBSDLimited lists: The following
lists require approval from core@FreeBSD.ORG to join,
though anyone is free to send messages to them which fall within
the scope of their charters. It is also a good idea establish a
presence in the technical lists before asking to join one of these
limited lists.ListPurposefreebsd-adminAdministrative issuesfreebsd-archArchitecture and design discussionsfreebsd-coreFreeBSD core teamfreebsd-hubsPeople running mirror sites (infrastructural
support)freebsd-installInstallation developmentfreebsd-security-notificationsSecurity notificationsfreebsd-user-groupsUser group coordinationCVS lists: The following lists
are for people interested in seeing the log messages for changes
to various areas of the source tree. They are Read-Only lists and should not have mail
sent to them.ListSource areaArea Description (source for)cvs-all/usr/srcAll changes to the tree (superset)How to subscribeAll mailing lists live on FreeBSD.ORG, so
to post to a given list you simply mail to
listname@FreeBSD.ORG. It will
then be redistributed to mailing list members world-wide.To subscribe to a list, send mail to &a.majordomo; and include
subscribe <listname> [<optional address>]
in the body of your message. For example, to
subscribe yourself to freebsd-announce, you'd do:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce
^DIf you want to subscribe yourself under a
different name, or submit a subscription request for a local
mailing list (this is more efficient if you have several
interested parties at one site, and highly appreciated by us!),
you would do something like:&prompt.user; mail majordomo@FreeBSD.ORG
subscribe freebsd-announce local-announce@somesite.com
^DFinally, it is also possible to unsubscribe
yourself from a list, get a list of other list members or see the
list of mailing lists again by sending other types of control
messages to majordomo. For a complete list of available commands,
do this:&prompt.user; mail majordomo@FreeBSD.ORG
help
^DAgain, we would like to request that you keep
discussion in the technical mailing lists on a technical track.
If you are only interested in the “high points” then it is
suggested that you join freebsd-announce, which is intended only
for infrequent traffic.List chartersAllFreeBSD mailing lists have
certain basic rules which must be adhered to by anyone using them.
Failure to comply with these guidelines will result in two (2)
written warnings from the FreeBSD Postmaster postmaster@freebsd.org, after
which, on a third offense, the poster will removed from all
FreeBSD mailing lists and filtered from further posting to them.
We regret that such rules and measures are necessary at all, but
today's Internet is a pretty harsh environment, it would seem, and
many fail to appreciate just how fragile some of its mechanisms
are.Rules of the road:The topic of any posting should adhere to the basic
charter of the list it is posted to, e.g. if the list is
about technical issues then your posting should contain
technical discussion. Ongoing irrelevant chatter or flaming
only detracts from the value of the mailing list for
everyone on it and will not be tolerated. For free-form
discussion on no particular topic, the freebsd-chat freebsd-chat@freebsd.org
mailing list is freely available and should be used
instead.No posting should be made to more than 2 mailing lists,
and only to 2 when a clear and obvious need to post to both
lists exists. For most lists, there is already a great deal
of subscriber overlap and except for the most esoteric mixes
(say "-stable & -scsi"), there really is no reason to
post to more than one list at a time. If a message is sent
to you in such a way that multiple mailing lists appear on
the Cc line then the cc line should also be trimmed before
sending it out again. You are still responsible for your own
cross-postings, no matter who the originator might have
been.Personal attacks and profanity (in the context of an
argument) are not allowed, and that includes users and
developers alike. Gross breaches of netiquette, like
excerpting or reposting private mail when permission to do
so was not and would not be forthcoming, are frowned upon
but not specifically enforced. However, there are also very few cases
where such content would fit within the charter of a list
and it would therefore probably rate a warning (or ban) on
that basis alone.Advertising of non-FreeBSD related products or services
is strictly prohibited and will result in an immediate ban
if it is clear that the offender is advertising by
spam.Individual list charters:FREEBSD-AFSAndrew File SystemThis list is for discussion on porting and using AFS from
CMU/TransarcFREEBSD-ADMINAdministrative issuesThis list is purely for discussion of freebsd.org
related issues and to report problems or abuse of project
resources. It is a closed list, though anyone may report
a problem (with our systems!) to it.FREEBSD-ANNOUNCEImportant events /
milestonesThis is the mailing list for people interested only
in occasional announcements of significant FreeBSD events.
This includes announcements about snapshots and other
releases. It contains announcements of new FreeBSD
capabilities. It may contain calls for volunteers etc.
This is a low volume, strictly moderated mailing
list.FREEBSD-ARCHArchitecture and design
discussionsThis is a moderated list for discussion of FreeBSD
architecture. Messages will mostly be kept technical in
nature, with (rare) exceptions for other messages the
moderator deems need to reach all the subscribers of the
list. Examples of suitable topics;How to re-vamp the build system to have several
customized builds running at the same time.What needs to be fixed with VFS to make Heidemann
layers work.How do we change the device driver interface to be
able to use the ame drivers cleanly on many buses and
architectures?How do I write a network driver?The moderator reserves the right to do minor editing
(spell-checking, grammar correction, trimming) of messages
that are posted to the list. The volume of the list will be
kept low, which may involve having to delay topics until an
active discussion has been resolved.FREEBSD-BUGSBug reportsThis is
the mailing list for reporting bugs in FreeBSD Whenever
possible, bugs should be submitted using the send-pr1
command or the WEB
interface to it.FREEBSD-CHATNon technical items related to the FreeBSD
communityThis list contains the
overflow from the other lists about non-technical, social
information. It includes discussion about whether Jordan
looks like a toon ferret or not, whether or not to type in
capitals, who is drinking too much coffee, where the best
beer is brewed, who is brewing beer in their basement, and
so on. Occasional announcements of important events (such
as upcoming parties, weddings, births, new jobs, etc) can
be made to the technical lists, but the follow ups should
be directed to this -chat list.FREEBSD-COREFreeBSD core teamThis is an internal mailing list for use by the core
members. Messages can be sent to it when a serious
FreeBSD-related matter requires arbitration or high-level
scrutiny.FREEBSD-CURRENTDiscussions about the use of
FreeBSD-currentThis is the
mailing list for users of freebsd-current. It includes
warnings about new features coming out in -current that
will affect the users, and instructions on steps that must
be taken to remain -current. Anyone running “current” must
subscribe to this list. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-CURRENT-DIGESTDiscussions about the use of
FreeBSD-currentThis is the
digest version of the freebsd-current mailing list. The
digest consists of all messages sent to freebsd-current
bundled together and mailed out as a single message. The
average digest size is about 40kB. This list is Read-Only and should not be posted
to.
- FREEBSD-STABLE
-
-
- Discussions about the use of
- FreeBSD-stable
-
- This is the
- mailing list for users of freebsd-stable. It includes
- warnings about new features coming out in -stable that
- will affect the users, and instructions on steps that must
- be taken to remain -stable. Anyone running “stable”
- should subscribe to this list. This is a technical mailing
- list for which strictly technical content is
- expected.
-
-
-
FREEBSD-DOCDocumentation project
- This mailing list is for the discussion of documentation
- related issues and projects. The members of this mailing list
- are collectively referred to as “The FreeBSD
- Documentation Project”. It is an open list; feel free to
- join and contribute.
+ This mailing list is for the discussion of issues and
+ projects related to the creation of documenation for
+ FreeBSD. The members of this mailing list are collectively
+ referred to as “The FreeBSD Documentation
+ Project”. It is an open list; feel free to join and
+ contribute!FREEBSD-FSFilesystemsDiscussions concerning FreeBSD filesystems. This is a
technical mailing list for which strictly technical
content is expected.FREEBSD-ISDNISDN CommunicationsThis is the mailing list for people discussing the
development of ISDN support for FreeBSD.FREEBSD-JAVAJava Development
This is the mailing list for people discussing the
development of significant Java applications for FreeBSD
and the porting and maintenance of JDKs.FREEBSD-HACKERSTechnical discussionsThis is a forum for technical discussions related to
FreeBSD. This is the primary technical mailing list. It
is for individuals actively working on FreeBSD, to bring
up problems or discuss alternative solutions. Individuals
interested in following the technical discussion are also
welcome. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-HACKERS-DIGESTTechnical discussionsThis is the digest version of the freebsd-hackers
mailing list. The digest consists of all messages sent to
freebsd-hackers bundled together and mailed out as a
single message. The average digest size is about 40kB.
This list is Read-Only and
should not be posted to.FREEBSD-HARDWAREGeneral discussion of FreeBSD
hardwareGeneral discussion
about the types of hardware that FreeBSD runs on, various
problems and suggestions concerning what to buy or
avoid.FREEBSD-INSTALLInstallation discussionThis mailing list is for discussing FreeBSD
installation development for the future releases and is
closed.FREEBSD-ISPIssues for Internet Service
ProvidersThis mailing list is
for discussing topics relevant to Internet Service
Providers (ISPs) using FreeBSD. This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-NEWBIESNewbies activities
discussionWe cover any of the activities of newbies that are not
already dealt with elsewhere, including: independent learning
and problem solving techniques, finding and using resources
and asking for help elsewhere, how to use mailing lists and
which lists to use, general chat, making mistakes, boasting,
sharing ideas, stories, moral (but not technical) support, and
taking an active part in the FreeBSD community. We take our
problems and support questions to freebsd-questions, and use
freebsd-newbies to meet others who are doing the same things
that we do as newbies.FREEBSD-PLATFORMSPorting to Non-Intel
platformsCross-platform freebsd
issues, general discussion and proposals for non-Intel
FreeBSD ports. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-PORTSDiscussion of
“ports”Discussions concerning FreeBSD's “ports collection”
(/usr/ports), proposed ports, modifications to ports
collection infrastructure and general coordination
efforts. This is a technical mailing list for which
strictly technical content is expected.FREEBSD-QUESTIONSUser questionsThis
is the mailing list for questions about FreeBSD. You
should not send “how to” questions to the technical lists
unless you consider the question to be pretty
technical.FREEBSD-QUESTIONS-DIGESTUser questionsThis
is the digest version of the freebsd-questions mailing
list. The digest consists of all messages sent to
freebsd-questions bundled together and mailed out as a
single message. The average digest size is about
40kB.FREEBSD-SCSISCSI subsystemThis
is the mailing list for people working on the scsi
subsystem for FreeBSD. This is a technical mailing list
for which strictly technical content is expected.FREEBSD-SECURITYSecurity issuesFreeBSD computer security issues (DES, Kerberos, known
security holes and fixes, etc). This is a technical
mailing list for which strictly technical content is
expected.FREEBSD-SECURITY-NOTIFICATIONSSecurity Notifications Notifications of FreeBSD security problems and fixes.
This is not a discussion list. The discussion list is
FreeBSD-security.FREEBSD-SMALLThis list discusses topics related to unsually small and
embedded FreeBSD installations. This is a technical mailing
list for which strictly technical content is expected.
- FREEBSD-USER-GROUPS
+ FREEBSD-STABLE
+
+
+ Discussions about the use of
+ FreeBSD-stable
+
+ This is the
+ mailing list for users of freebsd-stable. It includes
+ warnings about new features coming out in -stable that
+ will affect the users, and instructions on steps that must
+ be taken to remain -stable. Anyone running “stable”
+ should subscribe to this list. This is a technical mailing
+ list for which strictly technical content is
+ expected.
+
+
+
+ FREEBSD-USER-GROUPSUser Group Coordination
ListThis is the mailing list for the coordinators from
each of the local area Users Groups to discuss matters
with each other and a designated individual from the Core
Team. This mail list should be limited to meeting
synopsis and coordination of projects that span User
Groups. It is a closed list.Usenet newsgroupsIn addition to two FreeBSD specific newsgroups, there are many
others in which FreeBSD is discussed or are otherwise relevant to
FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.oz.au.BSD specific newsgroupscomp.unix.bsd.freebsd.announcecomp.unix.bsd.freebsd.miscOther Unix newsgroups of interestcomp.unixcomp.unix.questionscomp.unix.admincomp.unix.programmercomp.unix.shellcomp.unix.user-friendlycomp.security.unixcomp.sources.unixcomp.unix.advocacycomp.unix.misccomp.bugs.4bsdcomp.bugs.4bsd.ucb-fixescomp.unix.bsdX Window Systemcomp.windows.x.i386unixcomp.windows.xcomp.windows.x.appscomp.windows.x.announcecomp.windows.x.intrinsicscomp.windows.x.motifcomp.windows.x.pexcomp.emulators.ms-windows.wineWorld Wide Web servershttp://www.FreeBSD.ORG/ — Central Server.http://www.au.freebsd.org/FreeBSD/ — Australia.
+ URL="http://www.au.freebsd.org/FreeBSD/">http://www.au.freebsd.org/FreeBSD/ — Australia/1.
+
+
+
+ http://www2.au.freebsd.org/FreeBSD/ — Australia/2.
+
+
+
+ http://www3.au.freebsd.org/FreeBSD/ — Australia/3.
+
+
+
+ http://www.br.freebsd.org/www.freebsd.org/ — Brazil/1.
+
+
+
+ http://www.br2.freebsd.org/www.freebsd.org/ — Brazil/2.
+
+
+
+ http://www3.br.freebsd.org/ — Brazil/3.http://www.br.freebsd.org/ — Brazil.
+ URL="http://www.bg.freebsd.org/">http://www.bg.freebsd.org/ — Bulgaria.
http://www.ca.freebsd.org/ — Canada.
+ URL="http://www.ca.freebsd.org/">http://www.ca.freebsd.org/ — Canada/1.
http://sunsite.mff.cuni.cz/www.freebsd.org/ — Czech Republic.
+ URL="http://freebsd.kawartha.com/">http://freebsd.kawartha.com/ — Canada/2.
http://sunsite.auc.dk/www.freebsd.org/ — Denmark.
+ URL="http://www.dk.freebsd.org/">http://www.dk.freebsd.org/ — Denmark.
http://www.ee.freebsd.org/ — Estonia.http://www.fi.freebsd.org/ — Finland.
+
+
+ http://www.fr.freebsd.org/ — France.
+
+
+
+ http://www.de.freebsd.org/ — Germany/1.
+
+
+
+ http://www1.de.freebsd.org/ — Germany/2.
+
+
+
+ http://www.de.freebsd.org/ — Germany/3.
+
+
+
+ http://www.hu.freebsd.org/ — Hungary.
+ http://www.de.freebsd.org/ — Germany.
+ URL="http://www.is.freebsd.org/">http://www.is.freebsd.org/ — Iceland.
http://www.ie.freebsd.org/ — Ireland.http://www.jp.freebsd.org/ — Japan.
+ URL="http://www.jp.freebsd.org/www.freebsd.org/">http://www.jp.freebsd.org/www.freebsd.org/ — Japan.
http://www.kr.freebsd.org/ — Korea.
+
+ http://www.lv.freebsd.org/ — Latvia.
+
+
+
+ http://rama.asiapac.net/freebsd/ — Malaysia.
+
+
http://www.nl.freebsd.org/ — Netherlands.http://www.pt.freebsd.org/ — Portugal.
+ URL="http://www.no.freebsd.org/">http://www.no.freebsd.org/ — Norway.
+
+
+
+ http://www.pt.freebsd.org/ — Portugal/1.
+
+
+
+ http://www2.pt.freebsd.org/ — Portugal/2.
+
+
+
+ http://www3.pt.freebsd.org/ — Portugal/3.
+
+
+
+ http://www.ro.freebsd.org/ — Romania.
+
+
+
+ http://www.ru.freebsd.org/ — Russia/1.
+
+
+
+ http://www2.ru.freebsd.org/ — Russia/2.
+
+
+
+ http://www3.ru.freebsd.org/ — Russia/3.
+
+
+
+ http://www.sk.freebsd.org/ — Slovak Republic.
+
+
+
+ http://www.si.freebsd.org/ — Slovenia.
+
+
+
+ http://www.es.freebsd.org/ — Spain.
+
+
+
+ http://www.za.freebsd.org/ — South Africa/1.
+
+
+
+ http://www2.za.freebsd.org/ — South Africa/2.http://www.se.freebsd.org/www.freebsd.org/ — Sweden.http://www.tw.freebsd.org/freebsd.html — Taiwan.
+ URL="http://www.tr.freebsd.org/">http://www.tr.freebsd.org/ — Turkey.
+
+
+
+ http://www.ua.freebsd.org/ — Ukraine/1.
+
+
+
+ http://www2.ua.freebsd.org/ — Ukraine/2.
+
+
+
+ http://www.uk.freebsd.org/ — United Kingdom.
+
+
+
+ http://freebsd.advansys.net/ — USA/Indiana.http://www2.ua.freebsd.org/ — Ukraine.
+ URL="http://www6.freebsd.org/">http://www6.freebsd.org/ — USA/Oregon.
+
+ http://www2.freebsd.org/ — USA/Texas.
+
diff --git a/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml b/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml
index 163e13428a..77510aa99d 100644
--- a/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml
@@ -1,622 +1,626 @@
IntroductionFreeBSD is a 4.4BSD-Lite based operating system for Intel
architecture (x86) based PCs. For an overview of FreeBSD, see
FreeBSD in a nutshell. For a
history of the project, read a brief
history of FreeBSD. To see a description of the latest release,
read about the current
release. If you're interested in contributing something to the
FreeBSD project (code, equipment, sacks of unmarked bills), please see
about contributing to FreeBSD.FreeBSD in a NutshellFreeBSD is a state of the art operating system for personal
computers based on the Intel CPU architecture, which includes the
386, 486 and Pentium processors (both SX and DX versions). Intel
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
provides you with many advanced features previously available only
on much more expensive computers. These features include:Preemptive multitasking with
dynamic priority adjustment to ensure smooth and fair sharing
of the computer between applications and users.Multiuser access means that
many people can use a FreeBSD system simultaneously for a
variety of things. System peripherals such as printers and
tape drives are also properly SHARED BETWEEN ALL users on the
system.Complete TCP/IP networking
including SLIP, PPP, NFS and NIS support. This means that
your FreeBSD machine can inter-operate easily with other
systems as well act as an enterprise server, providing vital
functions such as NFS (remote file access) and e-mail services
or putting your organization on the Internet with WWW, ftp,
routing and firewall (security) services.Memory protection ensures
that applications (or users) cannot interfere with each other.
One application crashing will not affect others in any
way.FreeBSD is a 32-bit
operating system and was designed as such from the ground
up.The industry standard X Window
System (X11R6) provides a graphical user
interface (GUI) for the cost of a common VGA card and monitor
and comes with full sources.Binary compatibility with
many programs built for SCO, BSDI, NetBSD, Linux and
386BSD.Hundreds of ready-to-run
applications are available from the FreeBSD ports and packages collection. Why search the net
when you can find it all right here?Thousands of additional and easy-to-port applications available on
the Internet. FreeBSD is source code compatible with most
popular commercial Unix systems and thus most applications
require few, if any, changes to compile.Demand paged virtual memory
and “merged VM/buffer cache” design efficiently satisfies
applications with large appetites for memory while still
maintaining interactive response to other users.Shared libraries (the Unix
equivalent of MS-Windows DLLs) provide for efficient use of
disk space and memory.A full complement of C,
C++ and Fortran development tools. Many
additional languages for advanced research and development are
also available in the ports and packages collection.Source code for the entire
system means you have the greatest degree of control over your
environment. Why be locked into a proprietary solution and at
the mercy of your vendor when you can have a truly Open
System?Extensive on-line
documentation.And many more!FreeBSD is based on the 4.4BSD-Lite release from Computer
Systems Research Group (CSRG) at the University of California at
Berkeley, and carries on the distinguished tradition of BSD systems
development. In addition to the fine work provided by CSRG, the
FreeBSD Project has put in many thousands of hours in fine tuning
the system for maximum performance and reliability in real-life load
situations. As many of the commercial giants struggle to field PC
operating systems with such features, performance and reliability,
FreeBSD can offer them now!The applications to which FreeBSD can be put are truly limited
only by your own imagination. From software development to factory
automation, inventory control to azimuth correction of remote
satellite antennae; if it can be done with a commercial UNIX product
then it is more than likely that you can do it with FreeBSD, too!
FreeBSD also benefits significantly from the literally thousands of
high quality applications developed by research centers and
universities around the world, often available at little to no cost.
Commercial applications are also available and appearing in greater
numbers every day.Because the source code for FreeBSD itself is generally
available, the system can also be customized to an almost unheard of
degree for special applications or projects, and in ways not
generally possible with operating systems from most major commercial
vendors. Here is just a sampling of some of the applications in
which people are currently using FreeBSD:Internet Services: The
robust TCP/IP networking built into FreeBSD makes it an ideal
platform for a variety of Internet services such as:FTP serversWorld Wide Web serversGopher serversElectronic Mail serversUSENET NewsBulletin Board SystemsAnd more...You can easily start out small with an
inexpensive 386 class PC and upgrade as your enterprise
grows.Education: Are you a student
of computer science or a related engineering field? There is
no better way of learning about operating systems, computer
architecture and networking than the hands on, under the hood
experience that FreeBSD can provide. A number of freely
available CAD, mathematical and graphic design packages also
make it highly useful to those whose primary interest in a
computer is to get other work
done!Research: With source code
for the entire system available, FreeBSD is an excellent
platform for research in operating systems as well as other
branches of computer science. FreeBSD's freely available
nature also makes it possible for remote groups to collaborate
on ideas or shared development without having to worry about
special licensing agreements or limitations on what may be
discussed in open forums.Networking: Need a new
router? A name server (DNS)? A firewall to keep people out
of your internal network? FreeBSD can easily turn that unused
386 or 486 PC sitting in the corner into an advanced router
with sophisticated packet filtering capabilities.X Window workstation:
FreeBSD is a fine choice for an inexpensive X terminal
solution, either using the freely available XFree86 server or
one of the excellent commercial servers provided by X Inside.
Unlike an X terminal, FreeBSD allows many applications to be
run locally, if desired, thus relieving the burden on a
central server. FreeBSD can even boot “diskless”, making
individual workstations even cheaper and easier to
administer.Software Development: The
basic FreeBSD system comes with a full complement of
development tools including the renowned GNU C/C++ compiler
and debugger.FreeBSD is available in both source and binary form on CDROM and
via anonymous ftp. See Obtaining
FreeBSD for more details.A Brief History of FreeBSDContributed by &a.jkh;.The FreeBSD project had its genesis in the early part of 1993,
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
myself.Our original goal was to produce an intermediate snapshot of
386BSD in order to fix a number of problems with it that the
patchkit mechanism just was not capable of solving. Some of you may
remember the early working title for the project being “386BSD 0.5”
or “386BSD Interim” in reference to that fact.386BSD was Bill Jolitz's operating system, which had been up to
that point suffering rather severely from almost a year's worth of
neglect. As the patchkit swelled ever more uncomfortably with each
passing day, we were in unanimous agreement that something had to be
done and decided to try and assist Bill by providing this interim
“cleanup” snapshot. Those plans came to a rude halt when Bill
Jolitz suddenly decided to withdraw his sanction from the project
and without any clear indication of what would be done
instead.It did not take us long to decide that the goal remained
worthwhile, even without Bill's support, and so we adopted the name
“FreeBSD”, coined by David Greenman. Our initial objectives were
set after consulting with the system's current users and, once it
became clear that the project was on the road to perhaps even
becoming a reality, I contacted Walnut Creek CDROM with an eye
towards improving FreeBSD's distribution channels for those many
unfortunates without easy access to the Internet. Walnut Creek
CDROM not only supported the idea of distributing FreeBSD on CD but
went so far as to provide the project with a machine to work on and
a fast Internet connection. Without Walnut Creek CDROM's almost
unprecedented degree of faith in what was, at the time, a completely
unknown project, it is quite unlikely that FreeBSD would have gotten
as far, as fast, as it has today.The first CDROM (and general net-wide) distribution was FreeBSD
1.0, released in December of 1993. This was based on the
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
also provided by 386BSD and the Free Software Foundation. It was a
fairly reasonable success for a first offering, and we followed it
with the highly successful FreeBSD 1.1 release in May of
1994.Around this time, some rather unexpected storm clouds formed on
the horizon as Novell and U.C. Berkeley settled their long-running
lawsuit over the legal status of the Berkeley Net/2 tape. A
condition of that settlement was U.C. Berkeley's concession that
large parts of Net/2 were “encumbered” code and the property of
Novell, who had in turn acquired it from AT&T some time
previously. What Berkeley got in return was Novell's “blessing”
that the 4.4BSD-Lite release, when it was finally released, would be
declared unencumbered and all existing Net/2 users would be strongly
encouraged to switch. This included FreeBSD, and the project was
given until the end of July 1994 to stop shipping its own Net/2
based product. Under the terms of that agreement, the project was
allowed one last release before the deadline, that release being
FreeBSD 1.1.5.1.FreeBSD then set about the arduous task of literally
re-inventing itself from a completely new and rather incomplete set
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
Berkeley's CSRG had removed large chunks of code required for
actually constructing a bootable running system (due to various
legal requirements) and the fact that the Intel port of 4.4 was
highly incomplete. It took the project until December of 1994 to
make this transition, and in January of 1995 it released FreeBSD 2.0
to the net and on CDROM. Despite being still more than a little
rough around the edges, the release was a significant success and
was followed by the more robust and easier to install FreeBSD 2.0.5
release in June of 1995.We released FreeBSD 2.1.5 in August of 1996, and it appeared to
be popular enough among the ISP and commercial communities that
another release along the 2.1-stable branch was merited. This was
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
mainstream development on 2.1-stable. Now in maintenance mode, only
security enhancements and other critical bug fixes will be done on
this branch (RELENG_2_1_0).FreeBSD 2.2 was branched from the development mainline
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
first full release (2.2.1) was released in April, 1997. Further
releases along the 2.2 branch were done in the Summer and Fall of
'97, the latest being 2.2.7 which appeared in late July of '98.
- The first official 3.0 release will appear in October, 1998 and the
- last release on the 2.2 branch, 2.2.8, will appear in November.
-
- Long term development projects for everything from SMP to DEC
- ALPHA support will continue to take place in the 3.0-current branch
- and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).
-
+ The first official 3.0 release appeared in October, 1998 and the
+ last release on the 2.2 branch, 2.2.8, appeared in November,
+ 1998.
+
+ The tree branched again on Jan 20, 1999. This led to
+ 4.0-current and a 3.x-stable branch, from which 3.1 will be
+ released on February 15th, 1999.
+
+ Long term development projects will continue to take place in
+ the 4.0-current branch and SNAPshot releases of 4.0 on CDROM (and,
+ of course, on the net).FreeBSD Project GoalsContributed by &a.jkh;.The goals of the FreeBSD Project are to provide software that
may be used for any purpose and without strings attached. Many of
us have a significant investment in the code (and project) and would
certainly not mind a little financial compensation now and then, but
we're definitely not prepared to insist on it. We believe that our
first and foremost “mission” is to provide code to any and all
comers, and for whatever purpose, so that the code gets the widest
possible use and provides the widest possible benefit. This is, I
believe, one of the most fundamental goals of Free Software and one
that we enthusiastically support.That code in our source tree which falls under the GNU Public
License (GPL) or GNU Library Public License (GLPL) comes with
slightly more strings attached, though at least on the side of
enforced access rather than the usual opposite. Due to the
additional complexities that can evolve in the commercial use of GPL
software, we do, however, endeavor to replace such software with
submissions under the more relaxed BSD copyright whenever possible.The FreeBSD Development ModelContributed by &a.asami;.The development of FreeBSD is a very open and flexible process,
FreeBSD being literally built from the contributions of hundreds of
people around the world, as can be seen from our list of contributors. We are constantly
on the lookout for new developers and ideas, and those interested in
becoming more closely involved with the project need simply contact
us at the &a.hackers;. Those who prefer to work more independently
are also accommodated, and they are free to use our FTP facilities
at ftp.freebsd.org to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.Useful things to know about the FreeBSD project and its
development process, whether working independently or in close
cooperation:The CVS
repositoryThe central source tree for FreeBSD is maintained by
CVS (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary CVS repository resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the -current and -stable trees which are checked
out of it, can be easily replicated to your own machine as
well. Please refer to the
Synchronizing your source
tree section for more information on doing this.The committers
listThe committers
are the people who have write access to
the CVS tree, and are thus authorized to make modifications
to the FreeBSD source (the term “committer” comes from the
cvs1commit command, which is used to
bring new changes into the CVS repository). The best way of
making submissions for review by the committers list is to
use the send-pr1 command, though if something appears to be jammed in the system then you may also reach them by sending mail to committers@freebsd.org.The FreeBSD core
teamThe FreeBSD core
team would be equivalent to the board of directors if
the FreeBSD Project were a company. The primary task of the
core team is to make sure the project, as a whole, is in
good shape and is heading in the right directions. Inviting
dedicated and responsible developers to join our group of
committers is one of the functions of the core team, as is
the recruitment of new core team members as others move on.
Most current members of the core team started as committers
who's addiction to the project got the better of
them.Some core team members also have specific areas of responsibility,
meaning that they are committed to ensuring that some large
portion of the system works as advertised.Most members of the core team are volunteers when it
comes to FreeBSD development and do not benefit from the
project financially, so “commitment” should also not be
misconstrued as meaning “guaranteed support.” The
“board of directors” analogy above is not
actually very accurate, and it may be more suitable to say
that these are the people who gave up their lives in favor
of FreeBSD against their better judgement! ;)Outside
contributorsLast, but definitely not least, the largest group of
developers are the users themselves who provide feedback and
bug-fixes to us on an almost constant basis. The primary
way of keeping in touch with FreeBSD's more non-centralized
development is to subscribe to the &a.hackers; (see mailing list
info) where such things are discussed.The list of
those who have contributed something which made its way into
our source tree is a long and growing one, so why not join
it by contributing something back to FreeBSD today?
:-)Providing code is not the only way of contributing to
the project; for a more complete list of things that need
doing, please refer to the how to
contribute section in this handbook.In summary, our development model is organized as a loose set of
concentric circles. The centralized model is designed for the
convenience of the users of FreeBSD, who are
thereby provided with an easy way of tracking one central code base,
not to keep potential contributors out! Our desire is to present a
stable operating system with a large set of coherent application programs that the users can easily install
and use, and this model works very well in accomplishing
that.All we ask of those who would join us as FreeBSD developers is
some of the same dedication its current people have to its continued
success!About the Current ReleaseFreeBSD is a freely available, full source 4.4BSD-Lite based
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
compatible) based PC's. It is based primarily on software from U.C.
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
386BSD, and the Free Software Foundation.Since our release of FreeBSD 2.0 in January of 95, the
performance, feature set, and stability of FreeBSD has improved
dramatically. The largest change is a revamped virtual memory
system with a merged VM/file buffer cache that not only increases
performance, but reduces FreeBSD's memory footprint, making a 5MB
configuration a more acceptable minimum. Other enhancements include
full NIS client and server support, transaction TCP support,
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
bug fixes.We have also taken the comments and suggestions of many of our
users to heart and have attempted to provide what we hope is a more
sane and easily understood installation process. Your feedback on
this (constantly evolving) process is especially welcome!In addition to the base distributions, FreeBSD offers a new
ported software collection with hundreds of commonly sought-after
programs. At the end of August 1998 there were more than 1700 ports!
The list of ports ranges from http (WWW) servers, to games,
languages, editors and almost everything in between. The entire
ports collection requires approximately 26MB of storage, all ports
being expressed as “deltas” to their original sources. This
makes it much easier for us to update ports, and greatly reduces
the disk space demands made by the older 1.0 ports collection. To
compile a port, you simply change to the directory of the program
you wish to install, type make all followed by make install
after successful compilation and let the system do the rest. The
full original distribution for each port you build is retrieved
dynamically off the CDROM or a local ftp site, so you need only
enough disk space to build the ports you want. (Almost) every port
is also provided as a pre-compiled “package” which can be installed
with a simple command (pkg_add) by those who do not wish to compile
their own ports from source.A number of additional documents which you may find very helpful
in the process of installing and using FreeBSD may now also be found
in the /usr/share/doc directory on any machine
running FreeBSD 2.1 or later. You may view the locally installed
manuals with any HTML capable browser using the following
URLs:The FreeBSD handbookfile:/usr/share/doc/handbook/handbook.htmlThe FreeBSD FAQfile:/usr/share/doc/FAQ/FAQ.htmlYou can also visit the master (and most frequently updated)
copies at http://www.freebsd.org.The core of FreeBSD does not contain DES code which would
inhibit its being exported outside the United States. There is an
add-on package to the core distribution, for use only in the United
States, that contains the programs that normally use DES. The
auxiliary packages provided separately can be used by anyone. A
freely (from outside the U.S.) exportable European distribution of
DES for our non-U.S. users also exists and is described in the
FreeBSD FAQ.If password security for FreeBSD is all you need, and you have
no requirement for copying encrypted passwords from different hosts
(Suns, DEC machines, etc) into FreeBSD password entries, then
FreeBSD's MD5 based security may be all you require! We feel that
our default security model is more than a match for DES, and without
any messy export issues to deal with. If you are outside (or even
inside) the U.S., give it a try!
diff --git a/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml b/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml
index f40cd2f2d3..35d0fd1e36 100644
--- a/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml
@@ -1,1709 +1,1711 @@
Configuring the FreeBSD KernelContributed by &a.jehamby;.6 October
1995.This large section of the handbook discusses the basics of
building your own custom kernel for FreeBSD. This section is
appropriate for both novice system administrators and those with
advanced Unix experience.Why Build a Custom Kernel?Building a custom kernel is one of the most important rites of
passage every Unix system administrator must endure. This process,
while time-consuming, will provide many benefits to your FreeBSD
system. Unlike the GENERIC kernel, which must support every
possible SCSI and network card, along with tons of other rarely used
hardware support, a custom kernel only contains support for
your PC's hardware. This has a number of
benefits:It will take less time to boot because it does not have to
spend time probing for hardware which you do not have.A custom kernel often uses less memory, which is important
because the kernel is the one process which must always be
present in memory, and so all of that unused code ties up
pages of RAM that your programs would otherwise be able to
use. Therefore, on a system with limited RAM, building a
custom kernel is of critical importance.Finally, there are several kernel options which you can
tune to fit your needs, and device driver support for things
like sound cards which you can include in your kernel but are
not present in the GENERIC kernel.Building and Installing a Custom KernelFirst, let us take a quick tour of the kernel build directory.
All directories mentioned will be relative to the main
/usr/src/sys directory, which is also
accessible through /sys. There are a number of
subdirectories here representing different parts of the kernel, but
the most important, for our purposes, are
i386/conf, where you will edit your custom
kernel configuration, and compile,
which is the staging area where your kernel will be built. Notice
the logical organization of the directory tree, with each supported
device, filesystem, and option in its own subdirectory. Also,
anything inside the i386 directory deals with
PC hardware only, while everything outside the
i386 directory is common to all platforms which
FreeBSD could potentially be ported to.If there is not a
/usr/src/sys directory on your system, then
- the kernel source has not been been installed. Follow the
- instructions for installing packages to add this package to your
- system.
+ the kernel source has not been been installed. The easiest way
+ to do this is by running /stand/sysinstall as
+ root, choosing Configure,
+ then Distributions, then src,
+ then sys.
Next, move to the i386/conf directory and
copy the GENERIC configuration file to the name
you want to give your kernel. For example:&prompt.root; cd /usr/src/sys/i386/conf
&prompt.root; cp GENERIC MYKERNELTraditionally, this name is in all capital
letters and, if you are maintaining multiple FreeBSD machines with
different hardware, it is a good idea to name it after your
machine's hostname. We will call it MYKERNEL
for the purpose of this example.You must execute these and all of the following commands
under the root account or you will get permission denied
errors.Now, edit MYKERNEL with your favorite text
editor. If you are just starting out, the only editor available
will probably be vi, which is too
complex to explain here, but is covered well in many books in the
bibliography. Feel free to change
the comment lines at the top to reflect your configuration or the
changes you have made to differentiate it from
GENERIC.If you have build a kernel under SunOS or some other BSD
operating system, much of this file will be very familiar to you. If
you are coming from some other operating system such as DOS, on the
other hand, the GENERIC configuration file
might seem overwhelming to you, so follow the descriptions in the
Configuration File section slowly and carefully.If you are trying to upgrade your kernel from an older version
of FreeBSD, you will probably have to get a new version of
config8 from the same place you got the new
kernel sources. It is located in
/usr/src/usr.sbin, so you will need to
download those sources as well. Re-build and install it before
running the next commands.When you are finished, type the following to compile and install
your kernel:&prompt.root; /usr/sbin/config MYKERNEL
&prompt.root; cd ../../compile/MYKERNEL
&prompt.root; make depend
&prompt.root; make
&prompt.root; make installThe new kernel will be copied to the root
directory as /kernel and the old kernel will be
moved to /kernel.old. Now, shutdown the system
and reboot to use your kernel. In case something goes wrong, there
are some troubleshooting instructions at the end of this document.
Be sure to read the section which explains how to recover in case
your new kernel does not boot.If you have added any new devices (such as sound cards) you
may have to add some device nodes to your
/dev directory before you can use
them.The Configuration FileThe general format of a configuration file is quite simple. Each
line contains a keyword and one or more arguments. For simplicity,
most lines only contain one argument. Anything following a
# is considered a comment and ignored.
The following sections describe each keyword, generally in the order
they are listed in GENERIC, although some
related keywords have been grouped together in a single section
(such as Networking) even though they are actually scattered
throughout the GENERIC file.
An exhaustive list of options and
more detailed explanations of the device lines is present in the
LINT configuration file, located in the same
directory as GENERIC. If you are in doubt as to
the purpose or necessity of a line, check first in
LINT.The kernel is currently being moved to a better organization of
the option handling. Traditionally, each option in the config file
was simply converted into a switch for the
CFLAGS line of the kernel Makefile. Naturally,
this caused a creeping optionism, with nobody really knowing which
option has been referenced in what files.In the new scheme, every #ifdef
that is intended to be dependent upon an option gets this option out
of an opt_foo.h
declaration file created in the compile directory by config. The list of valid options for
config lives in two files: options
that do not depend on the architecture are listed in
/sys/conf/options, architecture-dependent ones
in
/sys/arch/conf/options.arch, with arch being for example i386.Mandatory KeywordsThese keywords are required in every kernel you build.machine "i386"The first keyword is machine, which, since FreeBSD only
runs on Intel 386 and compatible chips, is i386.Any keyword which contains numbers used as text
must be enclosed in quotation marks, otherwise
config gets confused and thinks you
mean the actual number 386.cpu "cpu_type"The next keyword is cpu,
which includes support for each CPU supported by FreeBSD.
The possible values of cpu_type
include:I386_CPUI486_CPUI586_CPUI686_CPUMultiple instances of the cpu line may be present with
different values of cpu_type
as are present in the GENERIC kernel.
For a custom kernel, it is best to specify only the cpu
you have. If, for example, you have an Intel Pentium, use
I586_CPU for cpu_type.ident machine_nameNext, we have ident,
which is the identification of the kernel. You should
change this from GENERIC to whatever
you named your kernel, in this example,
MYKERNEL. The value you put in
ident will print when you
boot up the kernel, so it is useful to give a kernel a
different name if you want to keep it separate from your
usual kernel (if you want to build an experimental kernel,
for example). Note that, as with machine and
cpu, enclose your kernel's name in quotation
marks if it contains any numbers.Since this name is passed to the C compiler as a
switch, do not use names like
DEBUG, or something that could be
confused with another machine or CPU name, like vax.maxusers numberThis file sets the size of a number of important
system tables. This number is supposed to be roughly
equal to the number of simultaneous users you expect to
have on your machine. However, under normal
circumstances, you will want to set
maxusers to at least 4,
especially if you are using the X Window System or
compiling software. The reason is that the most important
table set by maxusers is the
maximum number of processes, which is set to 20 + 16 *
maxusers, so if you set
maxusers to 1, then you
can only have 36 simultaneous processes, including the 18
or so that the system starts up at boot time, and the 15
or so you will probably create when you start the X Window
System. Even a simple task like reading a man page will start up nine
processes to filter, decompress, and view it. Setting
maxusers to 4 will allow you
to have up to 84 simultaneous processes, which should be
enough for anyone. If, however, you see the dreaded
proc table full error when trying to start another
program, or are running a server with a large number of
simultaneous users (like Walnut Creek CDROM's FTP site),
you can always increase this number and rebuild.maxuser does
not limit the number of users which
can log into your machine. It simply sets various table
sizes to reasonable values considering the maximum
number of users you will likely have on your system and
how many processes each of them will be running. One
keyword which does limit the number
of simultaneous remote logins is
pseudo-device pty
16.config kernel_name root on
root_deviceThis line specifies the location and name of the
kernel. Traditionally the kernel is called
vmunix but in FreeBSD, it is aptly
named kernel. You should always use
kernel for
kernel_name because changing it will
render numerous system utilities inoperative. The second
part of the line specifies the disk and partition where
the root filesystem and kernel can be found. Typically
this will be wd0 for systems
with non-SCSI drives, or sd0
for systems with SCSI drives.General OptionsThese lines provide kernel support for various filesystems and
other options.options MATH_EMULATEThis line allows the kernel to simulate a math
co-processor if your computer does not have one (386 or
486SX). If you have a Pentium, a 486DX, or a 386 or 486SX
with a separate 387 or 487 chip, you can comment this line
out.The normal math co-processor emulation routines that
come with FreeBSD are not very
accurate. If you do not have a math co-processor, and
you need the best accuracy, I recommend that you change
this option to GPL_MATH_EMULATE to use
the superior GNU math support, which is not included by
default for licensing reasons.options "COMPAT_43"Compatibility with 4.3BSD. Leave this in; some
programs will act strangely if you comment this
out.options BOUNCE_BUFFERSISA devices and EISA devices operating in an ISA
compatibility mode can only perform DMA (Direct Memory
Access) to memory below 16 megabytes. This option enables
such devices to work in systems with more than 16
megabytes of memory.options UCONSOLEAllow users to grab the console, useful for X Windows.
For example, you can create a console xterm by typing
xterm -C, which will display any
write, talk, and other messages you receive, as well
as any console messages sent by the kernel.options SYSVSHMThis option provides for System V shared memory. The
most common use of this is the XSHM extension in X
Windows, which many graphics-intensive programs (such as
the movie player XAnim, and Linux DOOM) will automatically
take advantage of for extra speed. If you use the X
Window System, you will definitely want to include
this.options SYSVSEMSupport for System V semaphores. Less commonly used
but only adds a few hundred bytes to the kernel.options SYSVMSGSupport for System V messages. Again, only adds a few
hundred bytes to the kernel.The ipcs1 command will tell
will list any processes using each of these System V
facilities.Filesystem OptionsThese options add support for various filesystems. You must
include at least one of these to support the device you boot from;
typically this will be FFS if you boot from a
hard drive, or NFS if you are booting a
diskless workstation from Ethernet. You can include other
commonly-used filesystems in the kernel, but feel free to comment
out support for filesystems you use less often (perhaps the MS-DOS
filesystem?), since they will be dynamically loaded from the
Loadable Kernel Module directory /lkm the
first time you mount a partition of that type.options FFSThe basic hard drive filesystem; leave it in if you
boot from the hard disk.options NFSNetwork Filesystem. Unless you plan to mount
partitions from a Unix file server over Ethernet, you can
comment this out.options MSDOSFSMS-DOS Filesystem. Unless you plan to mount a DOS
formatted hard drive partition at boot time, you can
safely comment this out. It will be automatically loaded
the first time you mount a DOS partition, as described
above. Also, the excellent mtools software (in the ports
collection) allows you to access DOS floppies without
having to mount and unmount them (and does not require
MSDOSFS at all).options "CD9660"ISO 9660 filesystem for CD-ROMs. Comment it out if
you do not have a CD-ROM drive or only mount data CD's
occasionally (since it will be dynamically loaded the
first time you mount a data CD). Audio CD's do not need
this filesystem.options PROCFSProcess filesystem. This is a pretend filesystem
mounted on /proc which allows
programs like ps1 to give you more
information on what processes are running.options MFSMemory-mapped file system. This is basically a RAM
disk for fast storage of temporary files, useful if you
have a lot of swap space that you want to take advantage
of. A perfect place to mount an MFS partition is on the
/tmp directory, since many programs
store temporary data here. To mount an MFS RAM disk on
/tmp, add the following line to
/etc/fstab and then reboot or type
mount /tmp:
/dev/wd1s2b /tmp mfs rw 0 0Replace the /dev/wd1s2b with
the name of your swap partition, which will be listed in
your /etc/fstab as follows:
/dev/wd1s2b none swap sw 0 0Also, the MFS filesystem can
not be dynamically loaded, so you
must compile it into your kernel if
you want to experiment with it.options "EXT2FS"Linux's native file system. With ext2fs support you
are able to read and write to Linux partitions. This is
useful if you dual-boot FreeBSD and Linux and want to
share data between the two systems.options QUOTAEnable disk quotas. If you have a public access
system, and do not want users to be able to overflow the
/home partition, you can establish
disk quotas for each user. Refer to the
Disk Quotas section for
more information.Basic Controllers and DevicesThese sections describe the basic disk, tape, and CD-ROM
controllers supported by FreeBSD. There are separate sections for
SCSI controllers and network cards.controller isa0All PC's supported by FreeBSD have one of these. If
you have an IBM PS/2 (Micro Channel Architecture), then
you cannot run FreeBSD at this time.controller pci0Include this if you have a PCI motherboard. This
enables auto-detection of PCI cards and gatewaying from
the PCI to the ISA bus.controller fdc0Floppy drive controller: fd0 is the
A: floppy drive, and
fd1 is the B: drive.
ft0 is a QIC-80 tape drive
attached to the floppy controller. Comment out any lines
corresponding to devices you do not have.QIC-80 tape support requires a separate filter
program called ft8, see the manual
page for details.controller wdc0This is the primary IDE controller. wd0 and wd1 are the master and slave hard
drive, respectively. wdc1 is
a secondary IDE controller where you might have a third or
fourth hard drive, or an IDE CD-ROM. Comment out the
lines which do not apply (if you have a SCSI hard drive,
you will probably want to comment out all six lines, for
example).device wcd0This device provides IDE CD-ROM support. Be sure to
leave wdc0 uncommented, and
wdc1 if you have more than
one IDE controller and your CD-ROM is on the second one
card. To use this, you must also include the line
options ATAPI.device npx0 at isa? port "IO_NPX" irq 13
vector npxintrnpx0 is the interface to
the floating point math unit in FreeBSD, either the
hardware co-processor or the software math emulator. It
is not optional.device wt0 at isa? port 0x300 bio irq 5 drq
1 vector wtintrWangtek and Archive QIC-02/QIC-36 tape drive
supportProprietary CD-ROM supportThe following drivers are for the so-called
proprietary CD-ROM drives. These
drives have their own controller card or might plug into a
sound card such as the SoundBlaster 16. They are
not IDE or SCSI. Most older
single-speed and double-speed CD-ROMs use these
interfaces, while newer quad-speeds are likely to be IDE or SCSI.device mcd0 at isa? port 0x300 bio
irq 10 vector mcdintrMitsumi CD-ROM (LU002, LU005, FX001D).device scd0 at isa? port 0x230
bioSony CD-ROM (CDU31, CDU33A).controller matcd0 at isa? port ?
bioMatsushita/Panasonic CD-ROM (sold by Creative
Labs for SoundBlaster).SCSI Device SupportThis section describes the various SCSI controllers and
devices supported by FreeBSD.SCSI ControllersThe next ten or so lines include support for different
kinds of SCSI controllers. Comment out all except for the
one(s) you have:controller bt0 at isa? port
"IO_BT0" bio irq ? vector btintrMost Buslogic controllerscontroller uha0 at isa? port
"IO_UHA0" bio irq ? drq 5 vector uhaintrUltraStor 14F and 34Fcontroller ahc0Adaptec 274x/284x/294xcontroller ahb0 at isa? bio irq ?
vector ahbintrAdaptec 174xcontroller aha0 at isa? port
"IO_AHA0" bio irq ? drq 5 vector ahaintrAdaptec 154xcontroller aic0 at isa? port
0x340 bio irq 11 vector aicintrAdaptec 152x and sound cards using Adaptec
AIC-6360 (slow!)controller nca0 at isa? port
0x1f88 bio irq 10 vector ncaintrProAudioSpectrum cards using NCR 5380 or
Trantor T130controller sea0 at isa? bio irq 5
iomem 0xc8000 iosiz 0x2000 vector seaintrSeagate ST01/02 8 bit controller
(slow!)controller wds0 at isa? port
0x350 bio irq 15 drq 6 vector wdsintrWestern Digital WD7000 controllercontroller ncr0NCR 53C810, 53C815, 53C825, 53C860, 53C875 PCI
SCSI controlleroptions "SCSI_DELAY=15"This causes the kernel to pause 15 seconds before
probing each SCSI device in your system. If you only have
IDE hard drives, you can ignore this, otherwise you will
probably want to lower this number, perhaps to 5 seconds,
to speed up booting. Of course if you do this, and
FreeBSD has trouble recognizing your SCSI devices, you
will have to raise it back up.controller scbus0If you have any SCSI controllers, this line provides
generic SCSI support. If you do not have SCSI, you can
comment this, and the following three lines, out.device sd0Support for SCSI hard drives.device st0Support for SCSI tape drives.device cd0Support for SCSI CD-ROM drives.Note that the number 0
in the above entries is slightly misleading: all these
devices are automatically configured as they are found,
regardless of how many of them are hooked up to the SCSI
bus(es), and which target IDs they have.If you want to “wire down” specific target IDs to
particular devices, refer to the appropriate section of
the LINT kernel config file.Console, Bus Mouse, and X Server SupportYou must choose one of these two console types, and, if you
plan to use the X Window System with the vt220 console, enable the
XSERVER option and optionally, a bus mouse or PS/2 mouse
device.device sc0 at isa? port "IO_KBD" tty irq 1
vector scintrsc0 is the default
console driver, which resembles an SCO console. Since most
full-screen programs access the console through a terminal
database library like termcap, it
should not matter much whether you use this or vt0, the VT220 compatible console
driver. When you log in, set your TERM variable to
“scoansi” if full-screen programs have trouble running
under this console.device vt0 at isa? port "IO_KBD" tty irq 1
vector pcrintThis is a VT220-compatible console driver, backwards
compatible to VT100/102. It works well on some laptops
which have hardware incompatibilities with sc0. Also, set your TERM variable
to vt100 or vt220 when you log in. This driver
might also prove useful when connecting to a large number
of different machines over the network, where the
termcap or
terminfo entries for the sc0 device are often not available
— vt100 should be available on virtually any
platform.options "PCVT_FREEBSD=210"Required with the vt0 console driver.options XSERVEROnly applicable with the vt0 console driver. This
includes code required to run the XFree86 X Window Server
under the vt0
console driver.device mse0 at isa? port 0x23c tty irq 5
vector msUse this device if you have a Logitech or ATI InPort
bus mouse card.If you have a serial mouse, ignore these two lines,
and instead, make sure the appropriate serial port is enabled (probably
COM1).device psm0 at isa? port "IO_KBD"
conflicts tty irq 12 vector psmintrUse this device if your mouse plugs into the PS/2
mouse port.Serial and Parallel PortsNearly all systems have these. If you are attaching a printer
to one of these ports, the Printing section of the handbook is very useful. If
you are using modem, Dialup access provides extensive detail on serial port
configuration for use with such devices.device sio0 at isa? port "IO_COM1" tty irq
4 vector siointrsio0 through sio3 are the four serial ports
referred to as COM1 through COM4 in the MS-DOS world.
Note that if you have an internal modem on COM4 and a
serial port at COM2 you will have to change the IRQ of the
modem to 2 (for obscure technical reasons IRQ 2 = IRQ 9)
in order to access it from FreeBSD. If you have a
multiport serial card, check the manual page for
sio4 for more information on the
proper values for these lines. Some video cards (notably
those based on S3 chips) use IO addresses of the form
0x*2e8, and since many cheap serial
cards do not fully decode the 16-bit IO address space,
they clash with these cards, making the COM4 port
practically unavailable.Each serial port is required to have a unique IRQ
(unless you are using one of the multiport cards where
shared interrupts are supported), so the default IRQs for
COM3 and COM4 cannot be used.device lpt0 at isa? port? tty irq 7 vector
lptintrlpt0 through lpt2 are the three printer ports you
could conceivably have. Most people just have one,
though, so feel free to comment out the other two lines if
you do not have them.NetworkingFreeBSD, as with Unix in general, places a
big emphasis on networking. Therefore, even
if you do not have an Ethernet card, pay attention to the
mandatory options and the dial-up networking support.options INETNetworking support. Leave it in even if you do not
plan to be connected to a network. Most programs require
at least loopback networking (i.e. making network
connections within your PC) so this is essentially
mandatory.Ethernet cardsThe next lines enable support for various Ethernet
cards. If you do not have a network card, you can comment
out all of these lines. Otherwise, you will want to leave
in support for your particular Ethernet card(s):device de0Ethernet adapters based on Digital Equipment
DC21040, DC21041 or DC21140 chipsdevice fxp0Intel EtherExpress Pro/100Bdevice vx03Com 3C590 and 3C595 (buggy)device cx0 at isa? port 0x240 net
irq 15 drq 7 vector cxintrCronyx/Sigma multiport sync/async (with Cisco
or PPP framing)device ed0 at isa? port 0x280 net
irq 5 iomem 0xd8000 vector edintrWestern Digital and SMC 80xx and 8216; Novell
NE1000 and NE2000; 3Com 3C503; HP PC Lan Plus
(HP27247B and HP27252A)device el0 at isa? port 0x300 net
irq 9 vector elintr3Com 3C501 (slow!)device eg0 at isa? port 0x310 net
irq 5 vector egintr3Com 3C505device ep0 at isa? port 0x300 net
irq 10 vector epintr3Com 3C509 (buggy)device fe0 at isa? port 0x240 net
irq ? vector feintrFujitsu MB86960A/MB86965A Ethernetdevice fea0 at isa? net irq ? vector
feaintrDEC DEFEA EISA FDDI adapterdevice ie0 at isa? port 0x360 net
irq 7 iomem 0xd0000 vector ieintrAT&T StarLAN 10 and EN100; 3Com 3C507;
unknown NI5210; Intel EtherExpress 16device le0 at isa? port 0x300 net
irq 5 iomem 0xd0000 vector le_intrDigital Equipment EtherWorks 2 and EtherWorks
3 (DEPCA, DE100, DE101, DE200, DE201, DE202,
DE203, DE204, DE205, DE422)device lnc0 at isa? port 0x300 net
irq 10 drq 0 vector lncintrLance/PCnet cards (Isolan, Novell NE2100,
NE32-VL)device xl03Com Etherlink XL series PCI ethernet
controllers (3C905B and related).device ze0 at isa? port 0x300 net
irq 5 iomem 0xd8000 vector zeintrIBM/National Semiconductor PCMCIA ethernet
controller.device zp0 at isa? port 0x300 net
irq 10 iomem 0xd8000 vector zpintr3Com PCMCIA Etherlink IIIWith certain cards (notably the NE2000) you will
have to change the port and/or IRQ since there is no
“standard” location for these cards.pseudo-device looploop is the generic
loopback device for TCP/IP. If you telnet or FTP to
localhost (a.k.a. 127.0.0.1) it will come back at you
through this pseudo-device. Mandatory.pseudo-device etherether is only needed if
you have an Ethernet card and includes generic Ethernet
protocol code.pseudo-device sl
numbersl is for SLIP (Serial
Line Internet Protocol) support. This has been almost
entirely supplanted by PPP, which is easier to set up,
better suited for modem-to-modem connections, as well as
more powerful. The number after
sl specifies how many
simultaneous SLIP sessions to support. This handbook has
more information on setting up a SLIP client or server.pseudo-device ppp
numberppp is for kernel-mode
PPP (Point-to-Point Protocol) support for dial-up Internet
connections. There is also version of PPP implemented as a
user application that uses the tun and offers more flexibility and
features such as demand dialing. If you still want to use
this PPP driver, read the kernel-mode PPP
section of the handbook. As with the sl device,
number specifies how many
simultaneous PPP connections to support.pseudo-device tun
numbertun is used by the
user-mode PPP software. This program is easy to set up and
very fast. It also has special features such as automatic
dial-on-demand. The number after tun specifies the number of
simultaneous PPP sessions to support. See the user-mode PPP section of the handbook for more
information.pseudo-device bpfilter
numberBerkeley packet filter. This pseudo-device allows
network interfaces to be placed in promiscuous mode,
capturing every packet on a broadcast network (e.g. an
ethernet). These packets can be captured to disk and/or
examined with the tcpdump1 program.
Note that implementation of this capability can seriously
compromise your overall network security. The
number after bpfilter is the number
of interfaces that can be examined simultaneously.
Optional, not recommended except for those who are fully
aware of the potential pitfalls. Not all network cards
support this capability.Sound cardsThis is the first section containing lines that are not in the
GENERIC kernel. To include sound card support, you will have to
copy the appropriate lines from the LINT kernel (which contains
support for every device) as follows:controller snd0Generic sound driver code. Required for all of the
following sound cards except pca.device pas0 at isa? port 0x388 irq 10 drq 6
vector pasintrProAudioSpectrum digital audio and MIDI.device sb0 at isa? port 0x220 irq 7
conflicts drq 1 vector sbintrSoundBlaster digital audio.If your SoundBlaster is on a different IRQ (such as
5), change irq 7 to, for
example, irq 5 and remove
the conflicts keyword.
Also, you must add the line: options
"SBC_IRQ=5"device sbxvi0 at isa? drq 5SoundBlaster 16 digital 16-bit audio.If your SB16 is on a different 16-bit DMA channel
(such as 6 or 7), change the drq
5 keyword appropriately, and then add the
line: options "SB16_DMA=6"device sbmidi0 at isa? port 0x330SoundBlaster 16 MIDI interface. If you have a
SoundBlaster 16, you must include this line, or the kernel
will not compile.device gus0 at isa? port 0x220 irq 10 drq 1
vector gusintrGravis Ultrasound.device mss0 at isa? port 0x530 irq 10 drq 1
vector adintrMicrosoft Sound System.device opl0 at isa? port 0x388
conflictsAdLib FM-synthesis audio. Include this line for
AdLib, SoundBlaster, and ProAudioSpectrum users, if you
want to play MIDI songs with a program such as playmidi (in the ports
collection).device mpu0 at isa? port 0x330 irq 6 drq
0Roland MPU-401 stand-alone card.device uart0 at isa? port 0x330 irq 5 vector
"m6850intr"Stand-alone 6850 UART for MIDI.device pca0 at isa? port "IO_TIMER1"
ttyDigital audio through PC speaker. This is going to be
very poor sound quality and quite CPU-intensive, so you
have been warned (but it does not require a sound
card).There is some additional documentation in
/usr/src/sys/i386/isa/sound/sound.doc.
Also, if you add any of these devices, be sure to create the
sound device nodes.Pseudo-devicesPseudo-device drivers are parts of the kernel that act like
device drivers but do not correspond to any actual hardware in the
machine. The network-related pseudo-devices are in that section,
while the remainder are here.pseudo-device gzipgzip allows you to run
FreeBSD programs that have been compressed with gzip. The programs in
/stand are compressed so it is a good
idea to have this option in your kernel.pseudo-device loglog is used for logging
of kernel error messages. Mandatory.pseudo-device pty
numberpty is a
“pseudo-terminal” or simulated login port. It is used
by incoming telnet and
rlogin sessions, xterm, and
some other applications such as emacs. The
number indicates the number of
ptys to create. If you need
more than GENERIC default of 16 simultaneous xterm windows
and/or remote logins, be sure to increase this number
accordingly, up to a maximum of 256.pseudo-device snp
numberSnoop device. This pseudo-device allows one terminal
session to watch another using the
watch8 command. Note that
implementation of this capability has important security
and privacy implications. The number
after snp is the total number of simultaneous snoop
sessions. Optional.pseudo-device vnVnode driver. Allows a file to be treated as a device
after being set up with the vnconfig8
command. This driver can be useful for manipulating
floppy disk images and using a file as a swap device (e.g.
an MS Windows swap file). Optional.pseudo-device ccd
numberConcatenated disks. This pseudo-device allows you to
concatenate multiple disk partitions into one large
“meta”-disk. The number after ccd
is the total number of concatenated disks (not total
number of disks that can be concatenated) that can be
created. (See ccd4 and
ccdconfig8 man pages for more
details.) Optional.Joystick, PC Speaker, MiscellaneousThis section describes some miscellaneous hardware devices
supported by FreeBSD. Note that none of these lines are included
in the GENERIC kernel, you will have to copy them from this
handbook or the LINT kernel (which contains support for
every device):device joy0 at isa? port "IO_GAME"PC joystick device.pseudo-device speakerSupports IBM BASIC-style noises through the PC
speaker. Some fun programs which use this are
/usr/sbin/spkrtest, which is a shell
script that plays some simple songs, and
/usr/games/piano which lets you play
songs using the keyboard as a simple piano (this file only
exists if you have installed the
games package). Also, the excellent
text role-playing game NetHack (in the ports collection)
can be configured to use this device to play songs when
you play musical instruments in the game.See also the pca0 device.Making Device NodesAlmost every device in the kernel has a corresponding “node”
entry in the /dev directory. These nodes look
like regular files, but are actually special entries into the kernel
which programs use to access the device. The shell script
/dev/MAKEDEV, which is executed when you first
install the operating system, creates nearly all of the device nodes
supported. However, it does not create all of
them, so when you add support for a new device, it pays to make sure
that the appropriate entries are in this directory, and if not, add
them. Here is a simple example:Suppose you add the IDE CD-ROM support to the kernel. The line
to add is:
controller wcd0This means that you should look for some entries
that start with wcd0 in the
/dev directory, possibly followed by a letter,
such as c, or preceded by the letter r, which means a “raw”
device. It turns out that those files are not there, so I must
change to the /dev directory and type:&prompt.root; sh MAKEDEV wcd0When this script finishes, you will find that
there are now wcd0c and rwcd0c entries in /dev so
you know that it executed correctly.For sound cards, the command:
&prompt.root; sh MAKEDEV snd0 creates the appropriate entries.When creating device nodes for devices such as sound cards, if
other people have access to your machine, it may be desirable to
protect the devices from outside access by adding them to the
/etc/fbtab file. See man
fbtab for more information.Follow this simple procedure for any other non-GENERIC devices
which do not have entries.All SCSI controllers use the same set of
/dev entries, so you do not need to create
these. Also, network cards and SLIP/PPP pseudo-devices do not
have entries in /dev at all, so you do not
have to worry about these either.If Something Goes WrongThere are four categories of trouble that can occur when
building a custom kernel. They are:Config command failsIf the config command
fails when you give it your kernel description, you have
probably made a simple error somewhere. Fortunately,
config will print the line
number that it had trouble with, so you can quickly skip to
it with vi. For example, if
you see:
config: line 17: syntax error you can skip to the problem in vi by typing 17G in command mode.
Make sure the keyword is typed correctly, by comparing it to
the GENERIC kernel or another reference.Make command failsIf the make command fails,
it usually signals an error in your kernel description, but
not severe enough for config
to catch it. Again, look over your configuration, and if
you still cannot resolve the problem, send mail to the
&a.questions; with your kernel configuration, and it should
be diagnosed very quickly.Kernel will not bootIf your new kernel does not boot, or fails to recognize
your devices, do not panic! Fortunately, BSD has an
excellent mechanism for recovering from incompatible
kernels. Simply type the name of the kernel you want to boot
from (i.e. kernel.old) at the FreeBSD boot prompt
instead of pressing return. When reconfiguring a kernel, it
is always a good idea to keep a kernel that is known to work
on hand.After booting with a good kernel you can check over your
configuration file and try to build it again. One helpful
resource is the /var/log/messages file
which records, among other things, all of the kernel
messages from every successful boot. Also, the
dmesg8 command will print the kernel
messages from the current boot.If you are having trouble building a kernel, make sure
to keep a GENERIC, or some other kernel that is known to
work on hand as a different name that will not get erased
on the next build. You cannot rely on
kernel.old because when installing a
new kernel, kernel.old is overwritten
with the last installed kernel which may be
non-functional. Also, as soon as possible, move the
working kernel to the proper kernel location or
commands such as ps1 will not work
properly. The proper command to “unlock” the
kernel file that make installs (in
order to move another kernel back permanently) is:&prompt.root; chflags noschg /kernelAnd, if you want to
“lock” your new kernel into place, or any
file for that matter, so that it cannot be moved or
tampered with:&prompt.root; chflags schg /kernelKernel works, but ps does not work any more!If you have installed a different version of the kernel
from the one that the system utilities have been built with,
for example, an experimental “2.2.0” kernel on a
2.1.0-RELEASE system, many system-status commands like
ps1 and vmstat8
will not work any more. You must recompile the libkvm library as well as these
utilities. This is one reason it is not normally a good
idea to use a different version of the kernel from the rest
of the operating system.
diff --git a/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml b/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml
index 0e2bc3b76d..044c736cf4 100644
--- a/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml
@@ -1,860 +1,860 @@
Linux EmulationContributed by &a.handy; and &a.rich;How to Install the Linux EmulatorLinux emulation in FreeBSD has reached a point where it is
possible to run a large fraction of Linux binaries in both a.out and
ELF format. The linux emulation in the 2.1-STABLE branch is capable
of running Linux DOOM and Mathematica; the version present in
&rel.current;-RELEASE is vastly more capable and runs all these as
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
other programs.There are some Linux-specific operating system features that are
not supported on FreeBSD. Linux binaries will not work on FreeBSD
if they use the Linux /proc filesystem (which
is different from the optional FreeBSD /proc
filesystem) or i386-specific calls, such as enabling virtual 8086
mode.Depending on which version of FreeBSD you are running, how you
get Linux-emulation up will vary slightly:Installing Linux Emulation in 2.1-STABLEThe GENERIC kernel in 2.1-STABLE is not
configured for linux compatibility so you must reconfigure your
kernel for it. There are two ways to do this: 1. linking the
emulator statically in the kernel itself and 2. configuring your
kernel to dynamically load the linux loadable kernel module
(LKM).To enable the emulator, add the following to your
configuration file (c.f.
/sys/i386/conf/LINT):
options COMPAT_LINUXIf you want to run doom or other applications
that need shared memory, also add the following.
options SYSVSHMThe linux system calls require 4.3BSD system
call compatibility. So make sure you have the following.
options "COMPAT_43"If you prefer to statically link the emulator in the kernel
rather than use the loadable kernel module (LKM), then add
options LINUXThen run config and install the new kernel as
described in the
kernel configuration
section.If you decide to use the LKM you must also install the
loadable module. A mismatch of versions between the kernel and
loadable module can cause the kernel to crash, so the safest thing
to do is to reinstall the LKM when you install the kernel.&prompt.root; cd /usr/src/lkm/linux
&prompt.root; make all installOnce you have installed the kernel and the LKM,
you can invoke `linux' as root to load the LKM.&prompt.root; linux
Linux emulator installed
Module loaded as ID 0To see whether the LKM is loaded, run
modstat.&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulatorYou can cause the LKM to be loaded when the
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
2.1-STABLE enable it in /etc/sysconfig
linux=YES by changing it from NO to YES. FreeBSD 2.1
RELEASE and earlier do not have such a line and on those you will
need to edit /etc/rc.local to add the following line.
linuxInstalling Linux Emulation in 2.2.2-RELEASE and laterIt is no longer necessary to specify options LINUX or
options COMPAT_LINUX. Linux emulation is done with an LKM
(“Loadable Kernel Module”) so it can be installed on the fly
without having to reboot. You will need the following things in
your startup files, however:In /etc/rc.conf, you need the
following line:
linux_enable=YESThis, in turn, triggers the following action in
/etc/rc.i386:
# Start the Linux binary emulation if requested.
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
linux'; linux > /dev/null 2>&1
fiIf you want to verify it is running, modstat will do that:&prompt.user; modstat
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 4 f09e6000 001c f09ec010 1 linux_modHowever, there have been reports that this
fails on some 2.2-RELEASE and later systems. If for some reason
you cannot load the linux LKM, then statically link the emulator
in the kernel by adding
options LINUX
to your kernel config file. Then run config
and install the new kernel as described in the kernel configuration section.Installing Linux Runtime LibrariesInstalling using the linux_lib portMost linux applications use shared libraries, so you are
still not done until you install the shared libraries. It is
possible to do this by hand, however, it is vastly simpler to
just grab the linux_lib port:&prompt.root; cd /usr/ports/emulators/linux_lib
&prompt.root; make all installand you should have a working linux emulator. Legend (and
the mail archives :-) seems to hold that Linux emulation works
best with linux binaries linked against the ZMAGIC libraries;
QMAGIC libraries (such as those used in Slackware V2.0) may tend
to give the Linuxulator heartburn. Also, expect some programs to complain
about incorrect minor versions of the system libraries. In
general, however, this does not seem
to be a problem.Installing libraries manuallyIf you do not have the “ports” distribution, you can
install the libraries by hand instead. You will need the Linux
shared libraries that the program depends on and the runtime
linker. Also, you will need to create a "shadow root"
directory, /compat/linux, for Linux
libraries on your FreeBSD system. Any shared libraries opened
by Linux programs run under FreeBSD will look in this tree
first. So, if a Linux program loads, for example,
/lib/libc.so, FreeBSD will first try to
open /compat/linux/lib/libc.so, and if that
does not exist then it will try
/lib/libc.so. Shared libraries should be
installed in the shadow tree
/compat/linux/lib rather than the paths
that the Linux ld.so reports.FreeBSD-2.2-RELEASE and later works slightly differently
with respect to /compat/linux: all files, not just
libraries, are searched for from the “shadow root”
/compat/linux.Generally, you will need to look for the shared libraries
that Linux binaries depend on only the first few times that you
install a Linux program on your FreeBSD system. After a while,
you will have a sufficient set of Linux shared libraries on your
system to be able to run newly imported Linux binaries without
any extra work.How to install additional shared librariesWhat if you install the linux_lib port and your application
still complains about missing shared libraries? How do you know
which shared libraries Linux binaries need, and where to get
them? Basically, there are 2 possibilities (when following these
instructions: you will need to be root on your FreeBSD system to
do the necessary installation steps).If you have access to a Linux system, see what shared
libraries the application needs, and copy them to your FreeBSD system.
Example: you have just ftp'ed the Linux binary of Doom. Put it
on the Linux system you have access to, and check which shared
libraries it needs by running ldd linuxxdoom:&prompt.user; ldd linuxxdoom
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29You would need to get all the files from the last column,
and put them under /compat/linux, with the
names in the first column as symbolic links pointing to them.
This means you eventually have these files on your FreeBSD
system:/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29Note that if you already have a Linux shared library with
a matching major revision number to the first column of the
ldd output, you will not need to copy the file named in the
last column to your system, the one you already have should
work. It is advisable to copy the shared library anyway if it
is a newer version, though. You can remove the old one, as
long as you make the symbolic link point to the new one. So,
if you have these libraries on your system:/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27and you find a new binary that claims to require a later
version according to the output of ldd:libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29If it is only one or two versions out of date in the in
the trailing digit then do not worry about copying
/lib/libc.so.4.6.29 too, because the
program should work fine with the slightly older version.
However, if you like you can decide to replace the
libc.so anyway, and that should leave you
with:/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29The symbolic link mechanism is only
needed for Linux binaries. The FreeBSD runtime linker takes
care of looking for matching major revision numbers itself and
you do not need to worry about it.Configuring the ld.so — for FreeBSD
2.2-RELEASE and laterThis section applies only to FreeBSD 2.2-RELEASE and later.
Those running 2.1-STABLE should skip this section.Finally, if you run FreeBSD 2.2-RELEASE you must make sure
that you have the Linux runtime linker and its config files on
your system. You should copy these files from the Linux system
to their appropriate place on your FreeBSD system (to the
/compat/linux tree):/compat/linux/lib/ld.so
/compat/linux/etc/ld.so.configIf you do not have access to a Linux system, you should get
the extra files you need from various ftp sites. Information on
where to look for the various files is appended below. For now,
let us assume you know where to get the files.Retrieve the following files (all from the same ftp site to
avoid any version mismatches), and install them under
/compat/linux (i.e.
/foo/bar is installed as
/compat/linux/foo/bar):/sbin/ldconfig
/usr/bin/ldd
/lib/libc.so.x.y.z
/lib/ld.soldconfig and ldd do not necessarily need to be under
/compat/linux; you can install them
elsewhere in the system too. Just make sure they do not conflict
with their FreeBSD counterparts. A good idea would be to install
them in /usr/local/bin as ldconfig-linux
and ldd-linux.Create the file
/compat/linux/etc/ld.so.conf, containing
the directories in which the Linux runtime linker should look
for shared libs. It is a plain text file, containing a directory
name on each line. /lib and
/usr/lib are standard, you could add the
following:
/usr/X11/lib
/usr/local/libWhen a linux binary opens a library such as
/lib/libc.so the emulator maps the name to
/compat/linux/lib/libc.so internally. All
linux libraries should be installed under /compat/linux (e.g.
/compat/linux/lib/libc.so,
/compat/linux/usr/X11/lib/libX11.so, etc.)
in order for the emulator to find them.Those running FreeBSD 2.2-RELEASE should run the Linux
ldconfig program.&prompt.root cd /compat/linux/lib
&prompt.root; /compat/linux/sbin/ldconfigldconfig is statically linked, so it does not need any
shared libraries to run. It creates the file
/compat/linux/etc/ld.so.cache which
contains the names of all the shared libraries and should be
rerun to recreate this file whenever you install additional
shared libraries.On 2.1-STABLE do not install
/compat/linux/etc/ld.so.cache or run
ldconfig; in 2.1-STABLE the syscalls are implemented differently
and ldconfig is not needed or used.You should now be set up for Linux binaries which only need
a shared libc. You can test this by running the Linux ldd on
itself. Supposing that you have it installed as ldd-linux, it
should produce something like:&prompt.root; ldd-linux `which ldd-linux`
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29This being done, you are ready to install new Linux
binaries. Whenever you install a new Linux program, you should
check if it needs shared libraries, and if so, whether you have
them installed in the /compat/linux tree.
To do this, you run the Linux version ldd on the new program,
and watch its output. ldd (see also the manual page for ldd1)
will print a list of shared libraries that the program depends
on, in the form majorname (jumpversion) => fullname.If it prints not found instead of fullname it means that
you need an extra library. The library needed is shown in
majorname and will be of the form libXXXX.so.N. You will need to
find a libXXXX.so.N.mm on a Linux ftp site, and install it on
your system. The XXXX (name) and N (major revision number)
should match; the minor number(s) mm are less important, though
it is advised to take the most recent version.Installing Linux ELF binariesELF binaries sometimes require an extra step of
“branding”. If you attempt to run an unbranded ELF binary,
you will get an error message like the following;&prompt.user; ./my-linux-elf-binary
ELF binary type not known
AbortTo help the FreeBSD kernel distinguish between a FreeBSD ELF
- binary from a Linux one, use the
+ binary from a Linux binary, use the brandelf1 utility.&prompt.user; brandelf -t Linux my-linux-elf-binaryThe GNU toolchain now places the appropriate branding information
into ELF binaries automatically, so you should be needing to do this
step increasingly rarely in future.Configuring the host name resolverIf DNS does not work or you get the messages
resolv+: "bind" is an invalid keyword resolv+:
"hosts" is an invalid keyword
then you need to configure a
/compat/linux/etc/host.conf file containing:
order hosts, bind
multi on
where the order here specifies that
/etc/hosts is searched first and DNS is
searched second. When
/compat/linux/etc/host.conf is not installed
linux applications find FreeBSD's
/etc/host.conf and complain about the
incompatible FreeBSD syntax. You should remove bind if you
have not configured a name-server using the
/etc/resolv.conf file.Lastly, those who run 2.1-STABLE need to set an the
RESOLV_HOST_CONF environment variable so that applications will
know how to search the host tables. If you run FreeBSD
2.2-RELEASE or later, you can skip this. For the
/bin/csh shell use:&prompt.user; setenv RESOLV_HOST_CONF /compat/linux/etc/host.confFor /bin/sh use:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFFinding the necessary filesThe information below is valid as of the time this document
was written, but certain details such as names of ftp sites,
directories and distribution names may have changed by the time
you read this.Linux is distributed by several groups that make their own set
of binaries that they distribute. Each distribution has its own
name, like “Slackware” or “Yggdrasil”. The distributions are
available on a lot of ftp sites. Sometimes the files are unpacked,
and you can get the individual files you need, but mostly they are
stored in distribution sets, usually consisting of subdirectories
with gzipped tar files in them. The primary ftp sites for the
distributions are:sunsite.unc.edu:/pub/Linux/distributionstsx-11.mit.edu:/pub/linux/distributionsSome European mirrors:ftp.luth.se:/pub/linux/distributionsftp.demon.co.uk:/pub/unix/linuxsrc.doc.ic.ac.uk:/packages/linux/distributionsFor simplicity, let us concentrate on Slackware here. This
distribution consists of a number of subdirectories, containing
separate packages. Normally, they are controlled by an install
program, but you can retrieve files “by hand” too. First of all,
you will need to look in the contents subdir of the
distribution. You will find a lot of small text files here
describing the contents of the separate packages. The fastest way
to look something up is to retrieve all the files in the contents
subdirectory, and grep through them for the file you need. Here is
an example of a list of files that you might need, and in which
contents-file you will find it by grepping through them:LibraryPackageld.soldso
ldconfigldso lddldso
libc.so.4shlibs libX11.so.6.0xf_lib
libXt.so.6.0xf_lib
libX11.so.3oldlibs
libXt.so.3oldlibs
So, in this case, you will need the packages ldso, shlibs,
xf_lib and oldlibs. In each of the contents-files for these
packages, look for a line saying PACKAGE LOCATION, it will
tell you on which “disk” the package is, in our case it will tell
us in which subdirectory we need to look. For our example, we
would find the following locations:PackageLocationldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9 The locations called “diskXX” refer to the slakware/XX
subdirectories of the distribution, others may be found in the
contrib subdirectory. In this case, we
could now retrieve the packages we need by retrieving the
following files (relative to the root of the Slackware
distribution tree):slakware/a2/ldso.tgzslakware/a2/shlibs.tgzslakware/x6/oldlibs/tgzslakware/x9/xf_lib.tgzExtract the files from these gzipped tarfiles in your
/compat/linux directory (possibly omitting or
afterwards removing files you do not need), and you are
done.See also:ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README and /usr/src/sys/i386/ibcs2/README.iBCS2How to Install Mathematica on FreeBSDContributed by &a.rich; and
&a.chuck;This document shows how to install the Linux binary distribution
of Mathematica 2.2 on FreeBSD 2.1.Mathematica supports Linux but not FreeBSD as it stands. So
once you have configured your system for Linux compatibility you
have most of what you need to run Mathematica.For those who already have the student edition of Mathematica
for DOS the cost of upgrading to the Linux version at the time this
was written, March 1996, was $45.00. It can be ordered directly
from Wolfram at (217) 398-6500 and paid for by credit card.Unpacking the Mathematica distributionThe binaries are currently distributed by Wolfram on CDROM.
The CDROM has about a dozen tar files, each of which is a binary
distribution for one of the supported architectures. The one for
Linux is named LINUX.TAR. You can, for
example, unpack this into
/usr/local/Mathematica:&prompt.root; cd /usr/local
&prompt.root; mkdir Mathematica
&prompt.root; cd Mathematica
&prompt.root; tar -xvf /cdrom/LINUX.TARObtaining your Mathematica PasswordBefore you can run Mathematica you will have to obtain a
password from Wolfram that corresponds to your “machine
ID”.Once you have installed the linux compatibility runtime
libraries and unpacked the mathematica you can obtain the “machine
ID” by running the program mathinfo in the Install directory.&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; mathinfo
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
richc.isdn.bcm.tmc.edu 9845-03452-90255So, for example, the “machine ID” of richc is
9845-03452-90255. You can ignore the message about the ioctl
that is not implemented. It will not prevent Mathematica from
running in any way and you can safely ignore it, though you will
see the message every time you run Mathematica.When you register with Wolfram, either by email, phone or fax,
you will give them the “machine ID” and they will respond with a
corresponding password consisting of groups of numbers. You need
to add them both along with the machine name and license number in
your mathpass file.You can do this by invoking:&prompt.root; cd /usr/local/Mathematica/Install
&prompt.root; math.installIt will ask you to enter your license number
and the Wolfram supplied password. If you get them mixed up or
for some reason the math.install fails, that is OK; you can simply
edit the file mathpass in this same directory to correct the
info manually.After getting past the password, math.install will ask you if
you accept the install defaults provided, or if you want to use
your own. If you are like us and distrust all install programs,
you probably want to specify the actual directories. Beware.
Although the math.install program asks you to specify directories,
it will not create them for you, so you should perhaps have a
second window open with another shell so that you can create them
before you give them to the install program. Or, if it fails, you
can create the directories and then restart the math.install
program. The directories we chose to create beforehand and
specify to math.install were:/usr/local/Mathematica/binfor binaries/usr/local/Mathematica/man/man1for man pages/usr/local/Mathematica/lib/X11for the XKeysymb fileYou can also tell it to use
/tmp/math.record for the system record file,
where it puts logs of sessions. After this math.install will
continue on to unpacking things and placing everything where it
should go.The Mathematica Notebook feature is included separately, as
the X Front End, and you have to install it separately. To get the
X Front End stuff correctly installed, cd into the
/usr/local/Mathematica/FrontEnd directory and
execute the xfe.install shell script. You will have to tell it
where to put things, but you do not have to create any directories
because it will use the same directories that had been created for
math.install. When it finishes, there should be a new shell script
in /usr/local/Mathematica/bin called
mathematica.Lastly, you need to modify each of the shell scripts that
Mathematica has installed. At the beginning of every shell script
in /usr/local/Mathematica/bin add the
following line:&prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDBThis tells Mathematica were to find its own
version of the key mapping file XKeysymDB.
Without this you will get pages of error messages about missing
key mappings.On 2.1-STABLE you need to add the following as well:&prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONFThis tells Mathematica to use the linux version
of host.conf. This file has a different syntax from FreeBSD's
host.conf, so you will get an error message about
/etc/host.conf if you leave this out.You might also want to modify your
/etc/manpath.config file to read the new man
directory, and you may need to edit your
~/.cshrc file to add
/usr/local/Mathematica/bin to your
path.That is about all it takes. With this you should be able to
type mathematica and get a really slick looking Mathematica
Notebook screen up. Mathematica has included the Motif user
interfaces, but it is compiled in statically, so you do not need
the Motif libraries. Good luck doing this yourself!BugsThe Notebook front end is known to hang sometimes when reading
notebook files with an error messages similar to:File .../Untitled-1.mb appears to be broken for OMPR.257.0We have not found the cause for this, but it only affects the
Notebook's X Window front end, not the mathematica engine itself.
So the command line interface invoked by 'math' is unaffected by
this bug.AcknowledgmentsA well-deserved thanks should go to &a.sos; and &a.peter; who
made linux emulation what it is today, and Michael Smith who drove
these two guys like dogs to get it to the point where it runs
Linux binaries better than linux! :-)
diff --git a/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml b/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml
index 18b2d73610..189309586a 100644
--- a/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/mail/chapter.sgml
@@ -1,593 +1,593 @@
Electronic MailContributed by &a.wlloyd;.Electronic Mail configuration is the subject of many System Administration books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.Some parts of E-Mail configuration are controlled in the Domain
Name System (DNS). If you are going to run your own own DNS server
check out /etc/namedb and man -k named for more information.Basic InformationThese are the major programs involved in an E-Mail exchange. A
“mailhost” is a server that is
responsible for delivering and receiving all email for your host,
and possibly your network.User programThis is a program like elm, pine,
mail, or something more sophisticated like a WWW
browser. This program will simply pass off all e-mail
transactions to the local “mailhost” ,
either by calling sendmail or
delivering it over TCP.Mailhost Server DaemonUsually this program is sendmail or
smail running in the background. Turn it off or
change the command line options in
/etc/rc.conf (or, prior to FreeBSD 2.2.2,
/etc/sysconfig). It is best to leave it on,
unless you have a specific reason to want it off. Example: You
are building a Firewall.You should be aware that sendmail is a potential weak link in a
secure site. Some versions of sendmail have known security
problems.sendmail does two jobs. It looks after delivering
and receiving mail.If sendmail
needs to deliver mail off your site it will look up in
the DNS to determine the actual host that will receive mail for
the destination.If it is acting as a delivery agent sendmail will take the message from the
local queue and deliver it across the Internet to another sendmail
on the receivers computer.DNS — Name ServiceThe Domain Name System and its daemon named, contain the database mapping
hostname to IP address, and hostname to mailhost. The IP address
is specified in an A record. The MX record specifies the
mailhost that will receive mail for you. If you do not have a
MX record mail for your hostname, the mail will be delivered to
your host directly.Unless you are running your own DNS server, you will not be
able to change any information in the DNS yourself. If you are
using an Internet Provider, speak to them.POP ServersThis program gets the mail from your mailbox and gives it to
your browser. If you want to run a POP server on your computer,
you will need to do 2 things.Get pop software from the Ports collection that
can be found in /usr/ports or packages
collection. This handbook section has a complete reference
on the Ports system.Modify /etc/inetd.conf
to load the POP server.The pop program will have instructions with it. Read
them.ConfigurationBasicAs your FreeBSD system comes “out of the box”[TM], you should
be able to send E-mail to external hosts as long as you have
/etc/resolv.conf setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods:Run a name server (man -k named) and have your own domain
smallminingco.com Get mail delivered to the current DNS name for your host.
Ie: dorm6.ahouse.school.edu No matter what option you choose, to have mail delivered
directly to your host, you must be a full Internet host. You must
have a permanent IP address. IE: NO dynamic PPP. If you are
behind a firewall, the firewall must be passing on smtp traffic to
you. From /etc/services:smtp 25/tcp mail #Simple Mail TransferIf you
want to receive mail at your host itself, you must make sure that
the DNS MX entry points to your host address, or there is no MX
entry for your DNS name.Try this:&prompt.root; hostname
newbsdbox.freebsd.org
&prompt.root; host newbsdbox.freebsd.org
newbsdbox.freebsd.org has address 204.216.27.xxIf that is all that comes out for your machine, mail directory
to root@newbsdbox.freebsd.org
will work no problems.If instead, you have this:&prompt.root; host newbsdbox.freebsd.org
newbsdbox.FreeBSD.org has address 204.216.27.xx
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.orgAll mail sent to your host
directly will end up on freefall, under the same username.This information is setup in your domain name server. This
should be the same host that is listed as your primary nameserver
in /etc/resolv.confThe DNS record that carries mail routing information is the
Mail eXchange entry. If no MX entry exists, mail will be
delivered directly to the host by way of the Address
record.The MX entry for freefall.freebsd.org at one time.
freefall MX 30 mail.crl.net
freefall MX 40 agora.rdrop.com
freefall HINFO Pentium FreeBSD
freefall MX 10 freefall.FreeBSD.org
freefall MX 20 who.cdrom.com
freefall A 204.216.27.xx
freefall CNAME www.FreeBSD.orgfreefall has many MX entries. The lowest MX number gets the
mail in the end. The others will queue mail temporarily, if
freefall is busy or down.Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other
friendly site can provide this service.dig, nslookup,
and host are your friends.Mail for your Domain (Network).To setup up a network mailhost, you need to direct the mail
from arriving at all the workstations. In other words, you want to
hijack all mail for *.smallminingco.com
and divert it to one machine, your “mailhost”.The network users on their workstations will most likely pick
up their mail over POP or telnet.A user account with the same username should exist on both
machines. Please use adduser to do
this as required. If you set the shell to
/nonexistent
the user will not be allowed to login.The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS
(ie BIND, named). Please refer to a Networking book for in-depth
information.You basically need to add these lines in your DNS server.
pc24.smallminingco.com A xxx.xxx.xxx.xxx ; Workstation ip
MX 10 smtp.smallminingco.com ; Your mailhostYou cannot do this yourself unless you are running a DNS
server. If you do not want to run a DNS server, get somebody else
like your Internet Provider to do it.This will redirect mail for the workstation to the Mail
eXchange host. It does not matter what machine the A record
points to, the mail will be sent to the MX host.This feature is used to implement Virtual E-Mail Hosting.ExampleI have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make
an entry in your DNS server like:
foo.bar MX 10 smtp.smalliap.com ; your mailhostThe A record is not needed if you only
want E-Mail for the domain. IE: Don't expect ping foo.bar
to work unless an Address record for foo.bar
exists as well.On the mailhost that actually accepts mail for final delivery
to a mailbox, sendmail must be told what hosts it will be
accepting mail for.Add pc24.smallminingco.com to /etc/sendmail.cw (if you are
using FEATURE(use_cw_file)), or add a Cw myhost.smalliap.com
line to /etc/sendmail.cfIf you plan on doing anything serious with sendmail you should install the sendmail
source. The source has plenty of documentation with it. You will
find information on getting sendmail
source from the UUCP
information.Setting up UUCP.Stolen from the FAQ.The sendmail configuration that ships with FreeBSD is suited
for sites that connect directly to the Internet. Sites that wish
to exchange their mail via UUCP must install another sendmail
configuration file.Tweaking /etc/sendmail.cf manually is
considered something for purists. Sendmail version 8 comes with a
new approach of generating config files via some m4 preprocessing, where the actual
hand-crafted configuration is on a higher abstraction level. You
should use the configuration files under
/usr/src/usr.sbin/sendmail/cf.If you did not install your system with full sources, the
sendmail config stuff has been broken out into a separate source
distribution tarball just for you. Assuming you have your CD-ROM
mounted, do:&prompt.root; cd /usr/src
&prompt.root; tar -xvzf /cdrom/dists/src/ssmailcf.aaDo not panic, this is only a few hundred kilobytes in size.
The file README in the cf directory can serve as a basic
introduction to m4 configuration.For UUCP delivery, you are best advised to use the
mailertable feature. This constitutes a
database that sendmail can use to base its routing decision
upon.First, you have to create your .mc file.
The directory
/usr/src/usr.sbin/sendmail/cf/cf is the home
of these files. Look around, there are already a few examples.
Assuming you have named your file foo.mc, all
you need to do in order to convert it into a valid
sendmail.cf is:&prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf
&prompt.root; make foo.cfIf you don't have a /usr/obj hiearchy,
then:&prompt.root; cp foo.cf /etc/sendmail.cfOtherwise:&prompt.root; cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cfA typical .mc file might look
like:
include(`../m4/cf.m4')
VERSIONID(`Your version number')
OSTYPE(bsd4.4)
FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)
define(`UUCP_RELAY', your.uucp.relay)
define(`UUCP_MAX_SIZE', 200000)
MAILER(local)
MAILER(smtp)
MAILER(uucp)
Cw your.alias.host.name
Cw youruucpnodename.UUCPThe nodns and
nocanonify features will prevent any usage of
the DNS during mail delivery. The UUCP_RELAY
clause is needed for bizarre reasons, do not ask. Simply put an
Internet hostname there that is able to handle .UUCP pseudo-domain
addresses; most likely, you will enter the mail relay of your ISP
there.Once you have this, you need this file called
/etc/mailertable. A typical example of this
gender again:
#
# makemap hash /etc/mailertable.db < /etc/mailertable
#
horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus
.heep.sax.de smtp8:%1 horus.UUCP
uucp-dom:horus if-bus.UUCP
uucp-dom:if-bus . uucp-dom:saxAs you can see, this is part of a real-life file. The first
three lines handle special cases where domain-addressed mail
should not be sent out to the default route, but instead to some
UUCP neighbor in order to “shortcut” the delivery path. The
next line handles mail to the local Ethernet domain that can be
delivered using SMTP. Finally, the UUCP neighbors are mentioned
in the .UUCP pseudo-domain notation, to allow for a
uucp-neighbor!recipient override of the default rules. The
last line is always a single dot, matching everything else, with
UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
uucp-dom: keyword must be valid UUCP
neighbors, as you can verify using the command uuname.As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish
this is best placed as a comment at the top of the mailertable.
You always have to execute this command each time you change your
mailertable.Final hint: if you are uncertain whether some particular mail
routing would work, remember the option to
sendmail. It starts sendmail
in “address test
mode”; simply enter 0, followed by the address
you wish to test for the mail routing. The last line tells you
the used internal mail agent, the destination host this agent will
be called with, and the (possibly translated) address. Leave this
mode by typing Control-D.&prompt.user; sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>0 foo@interface-business.de
rewrite: ruleset 0 input: foo @ interface-business . de
…
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . deFAQMigration from FAQ.Why do I have to use the FQDN for hosts on my site?You will probably find that the host is actually in a
different domain; for example, if you are in foo.bar.edu and you
wish to reach a host called mumble in the bar.edu domain, you
will have to refer to it by the fully-qualified domain name,
mumble.bar.edu, instead of just mumble.Traditionally, this was allowed by BSD BIND resolvers. However
the current version of BIND that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host mumble must either
be found as mumble.foo.bar.edu, or
it will be searched for in the root domain.This is different from the previous behavior, where the search
continued across mumble.bar.edu,
and mumble.edu. Have a look at
RFC 1535 for why this was considered bad practice, or even a
security hole.As a good workaround, you can place the line
search foo.bar.edu bar.edu
instead of the previous
domain foo.bar.edu
into your /etc/resolv.conf. However,
make sure that the search order does not go beyond the “boundary
between local and public administration”, as RFC 1535 calls
it.Sendmail says mail loops back to myselfThis is answered in the sendmail FAQ as follows:
* I am getting "Local configuration error" messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 <user@domain.net>... Local configuration error
How can I solve this problem?
You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine does not recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
to /etc/sendmail.cf.The sendmail FAQ is in
/usr/src/usr.sbin/sendmail and is recommended
reading if you want to do any “tweaking” of your mail
setup.How can I do E-Mail with a dialup PPP host?You want to connect a FreeBSD box on a lan, to the Internet.
The FreeBSD box will be a mail gateway for the lan. The PPP
connection is non-dedicated.There are at least two way to do this.The other is to use UUCP.The key is to get a Internet site to provide secondary MX
services for your domain. For example:
bigco.com. MX 10 bigco.com.
MX 20 smalliap.com.Only one host should be specified as the final recipient ( add
Cw bigco.com in /etc/sendmail.cf on
bigco.com).When the senders sendmail is trying to deliver the mail it
will try to connect to you over the modem link. It will most
likely time out because you are not online. sendmail will
automatically deliver it to the secondary MX site, ie your
Internet provider. The secondary MX site will try every
(sendmail_flags = "-bd -q15m" in
/etc/rc.conf ) 15 minutes to connect to your
host to deliver the mail to the primary MX site.
- You might wat to use something like this as a login script.
+ You might want to use something like this as a login script.
#!/bin/sh
# Put me in /usr/local/bin/pppbigco
( sleep 60 ; /usr/sbin/sendmail -q ) &
/usr/sbin/ppp -direct pppbigcoIf you are going to create a separate
login script for a user you could use sendmail
-qRbigco.com instead in the script above. This will
force all mail in your queue for bigco.com to be processed
immediately.A further refinement of the situation is as follows.Message stolen from the freebsd-isp mailing list.
> we provide the secondary mx for a customer. The customer connects to
> our services several times a day automatically to get the mails to
> his primary mx (We do not call his site when a mail for his domains
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
> moment he has to stay 30 minutes online to be sure that all mail is
> gone to the primary mx.
>
> Is there a command that would initiate sendmail to send all the mails
> now? The user has not root-privileges on our machine of course.
In the 'privacy flags' section of sendmail.cf, there is a definition
Opgoaway,restrictqrun
Remove restrictqrun to allow non-root users to start the queue processing.
You might also like to rearrange the MXs. We are the 1st MX for our
customers like this, and we have defined:
# If we are the best MX for a host, try directly instead of generating
# local config error.
OwTrue
That way a remote site will deliver straight to you, without trying
the customer connection. You then send to your customer. Only works for
"hosts", so you need to get your customer to name their mail machine
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
an A record in the DNS for "customer.com".
diff --git a/en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml
index 0f4423b959..5f1a569539 100644
--- a/en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml
@@ -1,1440 +1,1443 @@
Obtaining FreeBSDCD-ROM PublishersFreeBSD is available on CD-ROM from Walnut Creek CDROM:
Walnut Creek CDROM4041 Pike Lane, Suite FConcordCA, 94520USA
Phone: +1 925 674-0783
Fax: +1 925 674-0821
Email: info@cdrom.com
WWW: http://www.cdrom.com/FTP SitesThe official sources for FreeBSD are available via anonymous FTP
from:
ftp://ftp.FreeBSD.ORG/pub/FreeBSD.
The FreeBSD mirror
sites database is more accurate than the mirror listing in the
handbook, as it gets its information form the DNS rather than relying
on static lists of hosts.Additionally, FreeBSD is available via anonymous FTP from the
following mirror sites. If you choose to obtain FreeBSD via
anonymous FTP, please try to use a site near you.Argentina,
Australia,
Brazil,
Canada,
Czech Republic,
Denmark,
Estonia,
Spain,
Finland,
France,
Germany,
Hong Kong,
Ireland,
Israel,
Japan,
Korea,
Netherlands,
Poland,
Portugal,
Russia,
South Africa,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
Ukraine,
UK,
USA.ArgentinaIn case of problems, please contact the hostmaster hostmaster@ar.FreeBSD.ORG
for this domain.ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster hostmaster@au.FreeBSD.ORG
for this domain.ftp://ftp.au.FreeBSD.ORG/pub/FreeBSDftp://ftp2.au.FreeBSD.ORG/pub/FreeBSDftp://ftp3.au.FreeBSD.ORG/pub/FreeBSDftp://ftp4.au.FreeBSD.ORG/pub/FreeBSDBrazilIn case of problems, please contact the hostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDftp://ftp2.br.FreeBSD.ORG/pub/FreeBSDftp://ftp3.br.FreeBSD.ORG/pub/FreeBSDftp://ftp4.br.FreeBSD.ORG/pub/FreeBSDftp://ftp5.br.FreeBSD.ORG/pub/FreeBSDftp://ftp6.br.FreeBSD.ORG/pub/FreeBSDftp://ftp7.br.FreeBSD.ORG/pub/FreeBSDCanadaIn case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.ORG
for this domain.ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSDCzech Republicftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.DenmarkIn case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.ORG
for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.ORG
for this domain.ftp://ftp.ee.freebsd.ORG/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.ORG
for this domain.ftp://ftp.fi.freebsd.ORG/pub/FreeBSDFranceftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.GermanyIn case of problems, please contact the hostmaster hostmaster@de.FreeBSD.ORG
for this domain.ftp://ftp.de.FreeBSD.ORG/pub/FreeBSDftp://ftp2.de.FreeBSD.ORG/pub/FreeBSDftp://ftp3.de.FreeBSD.ORG/pub/FreeBSDftp://ftp4.de.FreeBSD.ORG/pub/FreeBSDftp://ftp5.de.FreeBSD.ORG/pub/FreeBSDftp://ftp6.de.FreeBSD.ORG/pub/FreeBSDftp://ftp7.de.FreeBSD.ORG/pub/FreeBSDHong Kongftp://ftp.hk.super.net/pub/FreeBSD Contact: ftp-admin@HK.Super.NET.IrelandIn case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.ORG
for this domain.ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster hostmaster@il.FreeBSD.ORG
for this domain.ftp://ftp.il.FreeBSD.ORG/pub/FreeBSDftp://ftp2.il.FreeBSD.ORG/pub/FreeBSDJapanIn case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.ORG
for this domain.ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSDKoreaIn case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.ORG
for this domain.ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp3.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp4.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp5.kr.FreeBSD.ORG/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.ORG
for this domain.ftp://ftp.nl.freebsd.ORG/pub/FreeBSDPolandIn case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.ORG
for this domain.ftp://ftp.pl.freebsd.ORG/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.ORG
for this domain.ftp://ftp.pt.freebsd.org/pub/FreeBSDftp://ftp2.pt.freebsd.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.ORG
for this domain.ftp://ftp.ru.freebsd.org/pub/FreeBSDftp://ftp2.ru.freebsd.org/pub/FreeBSDftp://ftp3.ru.freebsd.org/pub/FreeBSDftp://ftp4.ru.freebsd.org/pub/FreeBSDSouth AfricaIn case of problems, please contact the hostmaster hostmaster@za.FreeBSD.ORG
for this domain.ftp://ftp.za.FreeBSD.ORG/pub/FreeBSDftp://ftp2.za.FreeBSD.ORG/pub/FreeBSDftp://ftp3.za.FreeBSD.ORG/pub/FreeBSDSlovak RepublicIn case of problems, please contact the hostmaster
hostmaster@sk.FreeBSD.ORG for this domain.ftp://ftp.sk.freebsd.ORG/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster hostmaster@si.FreeBSD.ORG
for this domain.ftp://ftp.si.freebsd.ORG/pub/FreeBSDSpainIn case of problems, please contact the hostmaster
hostmaster@es.FreeBSD.ORG for this domain.ftp://ftp.es.freebsd.ORG/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster hostmaster@se.FreeBSD.ORG
for this domain.ftp://ftp.se.freebsd.ORG/pub/FreeBSDftp://ftp2.se.freebsd.ORG/pub/FreeBSDftp://ftp3.se.freebsd.ORG/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.ORG
for this domain.ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSDThailandftp://ftp.nectec.or.th/pub/FreeBSD Contact: ftpadmin@ftp.nectec.or.th.Ukraineftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: archer@lucky.net.
+ URL="ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD">ftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: freebsd-mnt@lucky.net.
UKIn case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.ORG
for this domain.ftp://ftp.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp2.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp3.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp4.uk.FreeBSD.ORG/pub/FreeBSDUSAIn case of problems, please contact the hostmaster hostmaster@FreeBSD.ORG for
this domain.ftp://ftp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.FreeBSD.ORG/pub/FreeBSDftp://ftp3.FreeBSD.ORG/pub/FreeBSDftp://ftp4.FreeBSD.ORG/pub/FreeBSDftp://ftp5.FreeBSD.ORG/pub/FreeBSDftp://ftp6.FreeBSD.ORG/pub/FreeBSDThe latest versions of export-restricted code for FreeBSD (2.0C
or later) (eBones and secure) are being made available at the
following locations. If you are outside the U.S. or Canada, please
get secure (DES) and eBones (Kerberos) from one of the following
foreign distribution sites:South AfricaHostmaster hostmaster@internat.FreeBSD.ORG for this domain.ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSDftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSDBrazilHostmaster hostmaster@br.FreeBSD.ORG
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.CTM SitesCTM/FreeBSD is available via
anonymous FTP from the following mirror sites. If you choose to
obtain CTM via anonymous FTP, please try to use a site near
you.In case of problems, please contact &a.phk;.California, Bay Area, official sourceftp://ftp.freebsd.org/pub/FreeBSD/CTMGermany, Trierftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTMSouth Africa, backup server for old
deltasftp://ftp.internat.freebsd.org/pub/FreeBSD/CTMTaiwan/R.O.C, Chiayiftp://ctm.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm2.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm3.tw.freebsd.org/pub/freebsd/CTMIf you did not find a mirror near to you or the mirror is
incomplete, try FTP
search at http://ftpsearch.ntnu.no/ftpsearch. FTP search is a great free archie server in Trondheim, Norway.CVSup SitesCVSup servers for FreeBSD are
running at the following sites:Argentinacvsup.ar.FreeBSD.ORG (maintainer msagre@cactus.fi.uba.ar)Australiacvsup.au.FreeBSD.ORG (maintainer dawes@physics.usyd.edu.au)Brazilcvsup.br.FreeBSD.ORG (maintainer cvsup@cvsup.br.freebsd.org)Canadacvsup.ca.FreeBSD.ORG (maintainer james@ican.net)Denmarkcvsup.dk.FreeBSD.ORG (maintainer
jesper@skriver.dk)Estoniacvsup.ee.FreeBSD.ORG (maintainer taavi@uninet.ee)Finlandcvsup.fi.FreeBSD.ORG (maintainer count@key.sms.fi)Germanycvsup.de.FreeBSD.ORG (maintainer wosch@freebsd.org)cvsup2.de.FreeBSD.ORG (maintainer petzi@freebsd.org)cvsup3.de.FreeBSD.ORG (maintainer ag@leo.org)Icelandcvsup.is.FreeBSD.ORG (maintainer
adam@veda.is)Japancvsup.jp.FreeBSD.ORG (maintainer simokawa@sat.t.u-tokyo.ac.jp)cvsup2.jp.FreeBSD.ORG (maintainer max@FreeBSD.ORG)cvsup3.jp.FreeBSD.ORG (maintainer
shige@cin.nihon-u.ac.jp)cvsup4.jp.FreeBSD.ORG (maintainer
cvsup-admin@ftp.media.kyoto-u.ac.jp)cvsup5.jp.FreeBSD.ORG (maintainer
cvsup@imasy.or.jp)Netherlandscvsup.nl.FreeBSD.ORG (maintainer xaa@xaa.iae.nl)Norwaycvsup.no.FreeBSD.ORG (maintainer Tor.Egge@idt.ntnu.no)Polandcvsup.pl.FreeBSD.ORG (maintainer Mariusz@kam.pl)Russiacvsup.ru.FreeBSD.ORG (maintainer mishania@demos.su)Swedencvsup.se.FreeBSD.ORG (maintainer pantzer@ludd.luth.se)Slovak Republiccvsup.sk.FreeBSD.ORG (maintainer
tps@tps.sk)cvsup2.sk.FreeBSD.ORG (maintainer
tps@tps.sk)South Africacvsup.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)cvsup2.za.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)Taiwancvsup.tw.FreeBSD.ORG (maintainer jdli@freebsd.csie.nctu.edu.tw)Ukraine
- cvsup2.ua.FreeBSD.ORG (maintainer archer@lucky.net)
+ cvsup2.ua.FreeBSD.ORG (maintainer freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer joe@pavilion.net)USAcvsup.FreeBSD.ORG (maintainer skynyrd@opus.cts.cwu.edu)cvsup2.FreeBSD.ORG (maintainer jdp@FreeBSD.ORG)cvsup3.FreeBSD.ORG (maintainer wollman@FreeBSD.ORG)
+
+ cvsup4.FreeBSD.ORG (maintainer shmit@rcn.com)
+ The export-restricted code for FreeBSD (eBones and secure) is
available via CVSup at the following international repository.
Please use this site to get the export-restricted code, if you are
outside the USA or Canada.South Africacvsup.internat.FreeBSD.ORG (maintainer markm@FreeBSD.ORG)The following CVSup site is especially designed for CTM users. Unlike the other CVSup mirrors,
it is kept up-to-date by CTM. That means if you CVSupcvs-all with release=cvs
from this site, you get a version of the repository (including the
inevitable .ctm_status file) which is
suitable for being updated using the CTMcvs-cur deltas. This allows users who track
the entire cvs-all tree to go from
CVSup to CTM without having to rebuild their repository from scratch
using a fresh CTM base delta.This special feature only works for the cvs-all distribution with
cvs as the release tag. CVSupping any other
distribution and/or release will get you the specified
distribution, but it will not be suitable for CTM updating.Because the current version of CTM does not preserve the
timestamps of files, the timestamps at this mirror site are not
the same as those at other mirror sites. Switching between this
site and other sites is not recommended. It will work correctly,
but will be somewhat inefficient.Germanyctm.FreeBSD.ORG (maintainer blank@fox.uni-trier.de)AFS SitesAFS servers for FreeBSD are running at the following sites;Swedenstacken.kth.se, Stacken
Computer Club, KTH, Sweden130.237.234.3, milko.stacken.kth.se130.237.234.43, hot.stacken.kth.se130.237.234.44, dog.stacken.kth.seMaintainer ftp@stacken.kth.se
diff --git a/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml b/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
index cb1b9b9d1f..4323cc68e1 100644
--- a/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
@@ -1,510 +1,579 @@
PGP keysIn case you need to verify a signature or send encrypted email to
one of the officers or core team members a number of keys are
provided here for your convenience.OfficersFreeBSD Security Officer security-officer@freebsd.org
FreeBSD Security Officer <security-officer@freebsd.org>
Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL
h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L
Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR
tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl
ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU
tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7
PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql
3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz
QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV
nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A
3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD
/REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb
5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS
9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B
sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P
BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT
0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx
ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD
ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO
v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1
lw==
=ipyA
-----END PGP PUBLIC KEY BLOCK-----&a.imp;
Warner Losh <imp@village.org>
aka <imp@freebsd.org>
Fingerprint = D4 31 FD B9 F7 90 17 E8 37 C5 E7 7F CF A6 C1 B9
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzDzTiAAAAEEAK8D7KWEbVFUrmlqhUEnAvphNIqHEbqqT8s+c5f5c2uHtlcH
V4mV2TlUaDSVBN4+/D70oHmZc4IgiQwMPCWRrSezg9z/MaKlWhaslc8YT6Xc1q+o
EP/fAdKUrq49H0QQbkQk6Ks5wKW6v9AOvdmsS6ZJEcet6d9G4dxynu/2qPVhAAUR
tCBNLiBXYXJuZXIgTG9zaCA8aW1wQHZpbGxhZ2Uub3JnPokAlQMFEDM/SK1VLh4u
c9KIpQEBFPsD/1n0YuuUPvD4CismZ9bx9M84y5sxLolgFEfP9Ux196ZSeaPpkA0g
C9YX/IyIy5VHh3372SDWN5iVSDYPwtCmZziwIV2YxzPtZw0nUu82P/Fn8ynlCSWB
5povLZmgrWijTJdnUWI0ApVBUTQoiW5MyrNN51H3HLWXGoXMgQFZXKWYiQCVAwUQ
MzmhkfUVW/uOVC1dAQG3+AP/T1HL/5EYF0ij0yQmNTzt1cLt0b1e3N3zN/wPFFWs
BfrQ+nsv1zw7cEgxLtktk73wBGM9jUIdJu8phgLtl5a0m9UjBq5oxrJaNJr6UTxN
a+sFkapTLT1g84UFUO/+8qRB12v+hZr2WeXMYjHAFUT18mp3xwjW9DUV+2fW1Wag
YDKJAJUDBRAzOYK1s1pi61mfMj0BARBbA/930CHswOF0HIr+4YYUs1ejDnZ2J3zn
icTZhl9uAfEQq++Xor1x476j67Z9fESxyHltUxCmwxsJ1uOJRwzjyEoMlyFrIN4C
dE0C8g8BF+sRTt7VLURLERvlBvFrVZueXSnXvmMoWFnqpSpt3EmN6TNaLe8Cm87a
k6EvQy0dpnkPKokAlQMFEDD9Lorccp7v9qj1YQEBrRUD/3N4cCMWjzsIFp2Vh9y+
RzUrblyF84tJyA7Rr1p+A7dxf7je3Zx5QMEXosWL1WGnS5vC9YH2WZwv6sCU61gU
rSy9z8KHlBEHh+Z6fdRMrjd9byPf+n3cktT0NhS23oXB1ZhNZcB2KKhVPlNctMqO
3gTYx+Nlo6xqjR+J2NnBYU8p =7fQV
-----END PGP PUBLIC KEY BLOCK-----Core Team members&a.asami;
Satoshi Asami <asami@cs.berkeley.edu>
aka <asami@FreeBSD.ORG>
Fingerprint = EB 3C 68 9E FB 6C EB 3F DB 2E 0F 10 8F CE 79 CA
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzPVyoQAAAEEAL7W+kipxB171Z4SVyyL9skaA7hG3eRsSOWk7lfvfUBLtPog
f3OKwrApoc/jwLf4+Qpdzv5DLEt/6Hd/clskhJ+q1gMNHyZ5ABmUxrTRRNvJMTrb
3fPU3oZj7sL/MyiFaT1zF8EaMP/iS2ZtcFsbYOqGeA8E/58uk4NA0SoeCNiJAAUR
tCVTYXRvc2hpIEFzYW1pIDxhc2FtaUBjcy5iZXJrZWxleS5lZHU+iQCVAwUQM/AT
+EqGN2HYnOMZAQF11QP/eSXb2FuTb1yX5yoo1Im8YnIk1SEgCGbyEbOMMBznVNDy
5g2TAD0ofLxPxy5Vodjg8rf+lfMVtO5amUH6aNcORXRncE83T10JmeM6JEp0T6jw
zOHKz8jRzygYLBayGsNIJ4BGxa4LeaGxJpO1ZEvRlNkPH/YEXK5oQmq9/DlrtYOJ
AEUDBRAz42JT8ng6GBbVvu0BAU8nAYCsJ8PiJpRUGlrz6rxjX8hqM1v3vqFHLcG+
G52nVMBSy+RZBgzsYIPwI5EZtWAKb22JAJUDBRAz4QBWdbtuOHaj97EBAaQPA/46
+NLUp+Wubl90JoonoXocwAg88tvAUVSzsxPXj0lvypAiSI2AJKsmn+5PuQ+/IoQy
lywRsxiQ5GD7C72SZ1yw2WI9DWFeAi+qa4b8n9fcLYrnHpyCY+zxEpu4pam8FJ7H
JocEUZz5HRoKKOLHErzXDiuTkkm72b1glmCqAQvnB4kAlQMFEDPZ3gyDQNEqHgjY
iQEBFfUEALu2C0uo+1Z7C5+xshWRYY5xNCzK20O6bANVJ+CO2fih96KhwsMof3lw
fDso5HJSwgFd8WT/sR+Wwzz6BAE5UtgsQq5GcsdYQuGI1yIlCYUpDp5sgswNm+OA
bX5a+r4F/ZJqrqT1J56Mer0VVsNfe5nIRsjd/rnFAFVfjcQtaQmjiQCVAwUQM9uV
mcdm8Q+/vPRJAQELHgP9GqNiMpLQlZig17fDnCJ73P0e5t/hRLFehZDlmEI2TK7j
Yeqbw078nZgyyuljZ7YsbstRIsWVCxobX5eH1kX+hIxuUqCAkCsWUY4abG89kHJr
XGQn6X1CX7xbZ+b6b9jLK+bJKFcLSfyqR3M2eCyscSiZYkWKQ5l3FYvbUzkeb6K0
IVNhdG9zaGkgQXNhbWkgPGFzYW1pQEZyZWVCU0QuT1JHPg==
=39SC
-----END PGP PUBLIC KEY BLOCK-----&a.jmb;
Jonathan M. Bresler <jmb@FreeBSD.org>
f16 Fingerprint16 = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNbtI
gAHbXdKX5jjdAQHamQP+OQr10QRknamIPmuHmFYJZ0jU9XPIvTTMuOiUYLcXlTdn
GyTUuzhbEywgtOldW2V5iA8platXThtqC68NsnN/xQfHA5xmFXVbayNKn8H5stDY
2s/4+CZ06mmJfqYmONF1RCbUk/M84rVT3Gn2tydsxFh4Pm32lf4WREZWRiLqmw+J
AJUDBRA0DfF99RVb+45ULV0BAcZ0BACCydiSUG1VR0a5DBcHdtin2iZMPsJUPRqJ
tWvP6VeI8OFpNWQ4LW6ETAvn35HxV2kCcQMyht1kMD+KEJz7r8Vb94TS7KtZnNvk
2D1XUx8Locj6xel5c/Lnzlnnp7Bp1XbJj2u/NzCaZQ0eYBdP/k7RLYBYHQQln5x7
BOuiRJNVU4kAlQMFEDQLcShVLh4uc9KIpQEBJv4D/3mDrD0MM9EYOVuyXik3UGVI
8quYNA9ErVcLdt10NjYc16VI2HOnYVgPRag3Wt7W8wlXShpokfC/vCNt7f5JgRf8
h2a1/MjQxtlD+4/Js8k7GLa53oLon6YQYk32IEKexoLPwIRO4L2BHWa3GzHJJSP2
aTR/Ep90/pLdAOu/oJDUiQCVAwUQMqyL0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz
2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyWCGw49XR/vPKYIJY9EYo4t49GIajRkISQ
NNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4dybo7oEKYMWWijQzGjqf2m8wf9OaaofE
KwBX6nxcRbKsxm/BVLKczGYl3XtjkcuJAJUDBRA1ol5TZWCprDT5+dUBATzXA/9h
/ZUuhoRKTWViaistGJfWi26FB/Km5nDQBr/Erw3XksQCMwTLyEugg6dahQ1u9Y5E
5tKPxbB69eF+7JXVHE/z3zizR6VL3sdRx74TPacPsdhZRjChEQc0htLLYAPkJrFP
VAzAlSlm7qd+MXf8fJovQs6xPtZJXukQukPNlhqZ94kAPwMFEDSH/kF4tXKgazlt
bxECfk4AoO+VaFVfguUkWX10pPSSfvPyPKqiAJ4xn8RSIe1ttmnqkkDMhLh00mKj
lLQuSm9uYXRoYW4gTS4gQnJlc2xlciA8Sm9uYXRoYW4uQnJlc2xlckBVU2kubmV0
PokAlQMFEDXbdSkB213Sl+Y43QEBV/4D/RLJNTrtAqJ1ATxXWv9g8Cr3/YF0GTmx
5dIrJOpBup7eSSmiM/BL9Is4YMsoVbXCI/8TqA67TMICvq35PZU4wboQB8DqBAr+
gQ8578M7Ekw1OAF6JXY6AF2P8k7hMcVBcVOACELPT/NyPNByG5QRDoNmlsokJaWU
/2ls4QSBZZlb
=zbCw
-----END PGP PUBLIC KEY BLOCK-----&a.ache;
Andrey A. Chernov <ache@FreeBSD.org>
aka <ache@nagual.pp.ru>
Key fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs
Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD
m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT
tCVBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucHAucnU+iQCVAwUQM2Ez
u+JgpPLZnQjrAQEyugP8DPnS8ixJ5OeuYgPFQf5sy6l+LrB6hyaS+lgsUPahWjNY
cnaDmfda/q/BV5d4+y5rlQe/pjnYG7/yQuAR3jhlXz8XDrqlBOnW9AtYjDt5rMfJ
aGFTGXAPGZ6k6zQZE0/YurT8ia3qjvuZm3Fw4NJrHRx7ETHRvVJDvxA6Ggsvmr20
JEFuZHJleSBBLiBDaGVybm92IDxhY2hlQEZyZWVCU0Qub3JnPokAlQMFEDR5uVbi
YKTy2Z0I6wEBLgED/2mn+hw4/3peLx0Sb9LNx//NfCCkVefSf2G9Qwhx6dvwbX7h
mFca97h7BQN4GubU1Z5Ffs6TeamSBrotBYGmOCwvJ6S9WigF9YHQIQ3B4LEjskAt
pcjU583y42zM11kkvEuQU2Gde61daIylJyOxsgpjSWpkxq50fgY2kLMfgl/ftCZB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuaWV0enNjaGUubmV0PokAlQMFEDR5svDi
YKTy2Z0I6wEBOTQD/0OTCAXIjuak363mjERvzSkVsNtIH9hA1l0w6Z95+iH0fHrW
xXKT0vBZE0y0Em+S3cotLL0bMmVE3F3D3GyxhBVmgzjyx0NYNoiQjYdi+6g/PV30
Cn4vOO6hBBpSyI6vY6qGNqcsawuRtHNvK/53MpOfKwSlICEBYQimcZhkci+EtCJB
bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJgpPLZ
nQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqKK8QY
rr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK/k7B
gI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFuZHJl
eSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+iQCV
AwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj4GPa
o3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI5apJ
mWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/osnzC
Cw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOvaoGr
anxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPriu8dI
rlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD7Hv8
vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZYMFO
DHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VSTGlh
Bhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+Mtun9
KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/YC3a
hs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1tGR3b
vz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwOTNQI
AOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fteFRkB
AWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96xnaa5
MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYiI0UA
Iwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAOz6qx
/IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBpYsfA
+6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzutZiM
1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cdiQCV
AwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgRsWFM
y9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8JkRv
Cn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6bLMV
HEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT1b14
5po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvlOm3R
rsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQPTi3
5SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qOx9Fw
erGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVjDHH5
+uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgbyldq6
EB33OunazFcfZFRIcXk1sfyLDvYE
=1ahV
-----END PGP PUBLIC KEY BLOCK-----&a.jkh;
Jordan K. Hubbard <jkh@FreeBSD.org>
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokBFQMFEDXCTXQM
j46yp4IfPQEBwO8IAIN0J09AXBf86dFUTFGcAMrEQqOF5IL+KGorAjzuYxERhKfD
ZV7jA+sCQqxkWfcVcE20kVyVYqzZIkio9a5zXP6TwA247JkPt54S1PmMDYHNlRIY
laXlNoji+4q3HP2DfHqXRT2859rYpm/fG/v6pWkos5voPKcZ2OFEp9W+Ap88oqw+
5rx4VetZNJq1Epmis4INj6XqNqj85+MOOIYE+f445ohDM6B/Mxazd6cHFGGIR+az
VjZ6lCDMLjzhB5+FqfrDLYuMjqkMTR5z9DL+psUvPlCkYbQ11NEWtEmiIWjUcNJN
GCxGzv5bXk0XPu3ADwbPkFE2usW1cSM7AQFiwuyJAJUDBRAxe+Q9a1pnjYGyp3kB
AV7XA/oCSL/Cc2USpQ2ckwkGpyvIkYBPszIcabSNJAzm2hsU9Qa6WOPxD8olDddB
uJNiW/gznPC4NsQ0N8Zr4IqRX/TTDVf04WhLmd8AN9SOrVv2q0BKgU6fLuk979tJ
utrewH6PR2qBOjAaR0FJNk4pcYAHeT+e7KaKy96YFvWKIyDvc4kAlQMFEDF8ldof
f6kIA1j8vQEBDH4D/0Zm0oNlpXrAE1EOFrmp43HURHbij8n0Gra1w9sbfo4PV+/H
U8ojTdWLy6r0+prH7NODCkgtIQNpqLuqM8PF2pPtUJj9HwTmSqfaT/LMztfPA6PQ
csyT7xxdXl0+4xTDl1avGSJfYsI8XCAy85cTs+PQwuyzugE/iykJO1Bnj/paiQCV
AwUQMXvlBvUVW/uOVC1dAQF2fQP/RfYC6RrpFTZHjo2qsUHSRk0vmsYfwG5NHP5y
oQBMsaQJeSckN4n2JOgR4T75U4vS62aFxgPLJP3lOHkU2Vc7xhAuBvsbGr5RP8c5
LvPOeUEyz6ZArp1KUHrtcM2iK1FBOmY4dOYphWyWMkDgYExabqlrAq7FKZftpq/C
BiMRuaw=
=C/Jw
-----END PGP PUBLIC KEY BLOCK-----&a.phk;
Poul-Henning Kamp <phk@FreeBSD.org>
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDQQ0aZ1
u244dqP3sQEBu4ID/jXFFeJgs2MdTDNOZM/FbfDhI4qxAbYUsqS3+Ra16yd8Wd/A
jV+IHJE2NomFWl8UrUjCGinXiwzPgK1OfFJrS9Og1wQLvAl0X84BA8MTP9BQr4w7
6I/RbksgUSrVCIO8MJwlydjSPocWGBeXlVjbZxXzyuJk7H+TG+zuI5BuBcNIiQCV
AwUQMwYr2rNaYutZnzI9AQHiIQP/XxtBWFXaBRgVLEhRNpS07YdU+LsZGlLOZehN
9L4UnJFHQQPNOpMey2gF7Y95aBOw5/1xS5vlQpwmRFCntWsm/gqdzK6rulfr1r5A
y94LO5TAC6ucNu396Y4vo1TyD1STnRC466KlvmtQtAtFGgXlORWLL9URLzcRFd1h
D0yXd9aJAJUDBRAxfo19a1pnjYGyp3kBAQqyA/4v64vP3l1F0Sadn6ias761hkz/
SMdTuLzILmofSCC4o4KWMjiWJHs2Soo41QlZi1+xMHzV32JKiwFlGtPHqL+EHyXy
Q4H3vmf9/1KF+0XCaMtgI0wWUMziPSTJK8xXbRRmMDK/0F4TnVVaUhnmf+h5K7O6
XdmejDTa0X/NWcicmIkAlQMFEDF8lef1FVv7jlQtXQEBcnwD/0ro1PpUtlkLmreD
tsGTkNa7MFLegrYRvDDrHOwPZH152W2jPUncY+eArQJakeHiTDmJNpFagLZglhE0
bqJyca+UwCXX+6upAclWHEBMg2byiWMMqyPVEEnpUoHM1sIkgdNWlfQAmipRBfYh
2LyCgWvR8CbtwPYIFvUmGgB3MR87iQCVAwUQMUseXB9/qQgDWPy9AQGPkwP/WEDy
El2Gkvua9COtMAifot2vTwuvWWpNopIEx0Ivey4aVbRLD90gGCJw8OGDEtqFPcNV
8aIiy3fYVKXGZZjvCKd7zRfhNmQn0eLDcymq2OX3aPrMc2rRlkT4Jx425ukR1gsO
qiQAgw91aWhY8dlw/EKzk8ojm52x4VgXaBACMjaJAJUDBRAxOUOg72G56RHVjtUB
AbL4A/9HOn5Qa0lq9tKI/HkSdc5fGQD/66VdCBAb292RbB7CS/EM07MdbcqRRYIa
0+0gwQ3OdsWPdCVgH5RIhp/WiC+UPkR1cY8N9Mg2kTwJfZZfNqN+BgWlgRMPN27C
OhYNl8Q33Nl9CpBLrZWABF44jPeT0EvvTzP/5ZQ7T75EsYKYiYkAlQMFEDDmryQA
8tkJ67sbQQEBPdsEALCj6v1OBuJLLJTlxmmrkqAZPVzt5QdeO3Eqa2tcPWcU0nqP
vHYMzZcZ7oFg58NZsWrhSQQDIB5e+K65Q/h6dC7W/aDskZd64jxtEznX2kt0/MOr
8OdsDis1K2f9KQftrAx81KmVwW4Tqtzl7NWTDXt44fMOtibCwVq8v2DFkTJy
=JKbP
-----END PGP PUBLIC KEY BLOCK-----&a.rich;
Rich Murphey <rich@FreeBSD.org>
fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1
FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs
wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR
tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W
vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g
Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP
/2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw==
=QoiM
-----END PGP PUBLIC KEY BLOCK-----&a.jdp;
John D. Polstra <jdp@polstra.com>
Fingerprint = 54 3A 90 59 6B A4 9D 61 BF 1D 03 09 35 8D F6 0D
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzMElMEAAAEEALizp6ZW9QifQgWoFmG3cXhzQ1+Gt+a4S1adC/TdHdBvw1M/
I6Ok7TC0dKF8blW3VRgeHo4F3XhGn+n9MqIdboh4HJC5Iiy63m98sVLJSwyGO4oM
dkEGyyCLxqP6h/DU/tzNBdqFzetGtYvU4ftt3RO0a506cr2CHcdm8Q+/vPRJAAUR
tCFKb2huIEQuIFBvbHN0cmEgPGpkcEBwb2xzdHJhLmNvbT6JAJUDBRAzBNBE9RVb
+45ULV0BAWgiA/0WWO3+c3qlptPCHJ3DFm6gG/qNKsY94agL/mHOr0fxMP5l2qKX
O6a1bWkvGoYq0EwoKGFfn0QeHiCl6jVi3CdBX+W7bObMcoi+foqZ6zluOWBC1Jdk
WQ5/DeqQGYXqbYjqO8voCScTAPge3XlMwVpMZTv24u+nYxtLkE0ZcwtY9IkAlQMF
EDMEt/DHZvEPv7z0SQEBXh8D/2egM5ckIRpGz9kcFTDClgdWWtlgwC1iI2p9gEhq
aufy+FUJlZS4GSQLWB0BlrTmDC9HuyQ+KZqKFRbVZLyzkH7WFs4zDmwQryLV5wkN
C4BRRBXZfWy8s4+zT2WQD1aPO+ZsgRauYLkJgTvXTPU2JCN62Nsd8R7bJS5tuHEm
7HGmiQCVAwUQMwSvHB9/qQgDWPy9AQFAhAQAgJ1AlbKITrEoJ0+pLIsov3eQ348m
SVHEBGIkU3Xznjr8NzT9aYtq4TIzt8jplqP3QoV1ka1yYpZf0NjvfZ+ffYp/sIaU
wPbEpgtmHnVWJAebMbNs/Ad1w8GDvxEt9IaCbMJGZnHmfnEqOBIxF7VBDPHHoJxM
V31K/PIoYsHAy5w=
=cHFa
-----END PGP PUBLIC KEY BLOCK-----&a.guido;
Guido van Rooij <guido@gvr.win.tue.nl>
Fingerprint = 16 79 09 F3 C0 E4 28 A7 32 62 FA F6 60 31 C0 ED
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzGeO84AAAEEAKKAY91Na//DXwlUusr9GVESSlVwVP6DyH1wcZXhfN1fyZHq
SwhMCEdHYoojQds+VqD1iiZQvv1RLByBgj622PDAPN4+Z49HjGs7YbZsUNuQqPPU
wRPpP6ty69x1hPKq1sQIB5MS4radpCM+4wbZbhxv7l4rP3RWUbNaYutZnzI9AAUR
tCZHdWlkbyB2YW4gUm9vaWogPGd1aWRvQGd2ci53aW4udHVlLm5sPokAlQMFEDMG
Hcgff6kIA1j8vQEBbYgD/jm9xHuUuY+iXDkOzpCXBYACYEZDV913MjtyBAmaVqYo
Rh5HFimkGXe+rCo78Aau0hc57fFMTsJqnuWEqVt3GRq28hSK1FOZ7ni9/XibHcmN
rt2yugl3hYpClijo4nrDL1NxibbamkGW/vFGcljS0jqXz6NDVbGx5Oo7HBByxByz
iQCVAwUQMhmtVjt/x7zOdmsfAQFuVQQApsVUTigT5YWjQA9Nd5Z0+a/oVtZpyw5Z
OljLJP3vqJdMa6TidhfcatjHbFTve5x1dmjFgMX/MQTd8zf/+Xccy/PX4+lnKNpP
eSf1Y4aK+E8KHmBGd6GzX6CIboyGYLS9e3kGnN06F2AQtaLyJFgQ71wRaGuyKmQG
FwTn7jiKb1aJAJUDBRAyEOLXPt3iN6QQUSEBATwQA/9jqu0Nbk154+Pn+9mJX/YT
fYR2UqK/5FKCqgL5Nt/Deg2re0zMD1f8F9Dj6vuAAxq8hnOkIHKlWolMjkRKkzJi
mSPEWl3AuHJ31k948J8it4f8kq/o44usIA2KKVMlI63Q/rmNdfWCyiYQEVGcRbTm
GTdZIHYCOgV5dOo4ebFqgYkAlQMFEDIE1nMEJn15jgpJ0QEBW6kEAKqN8XSgzTqf
CrxFXT07MlHhfdbKUTNUoboxCGCLNW05vf1A8F5fdE5i14LiwkldWIzPxWD+Sa3L
fNPCfCZTaCiyGcLyTzVfBHA18MBAOOX6JiTpdcm22jLGUWBf/aJK3yz/nfbWntd/
LRHysIdVp29lP5BF+J9/Lzbb/9LxP1taiQCVAwUQMgRXZ44CzbsJWQz9AQFf7gP/
Qa2FS5S6RYKG3rYanWADVe/ikFV2lxuM1azlWbsmljXvKVWGe6cV693nS5lGGAjx
lbd2ADwXjlkNhv45HLWFm9PEveO9Jjr6tMuXVt8N2pxiX+1PLUN9CtphTIU7Yfjn
s6ryZZfwGHSfIxNGi5ua2SoXhg0svaYnxHxXmOtH24iJAJUDBRAyAkpV8qaAEa3W
TBkBARfQBAC+S3kbulEAN3SI7/A+A/dtl9DfZezT9C4SRBGsl2clQFMGIXmMQ/7v
7lLXrKQ7U2zVbgNfU8smw5h2vBIL6f1PyexSmc3mz9JY4er8KeZpcf6H0rSkHl+i
d7TF0GvuTdNPFO8hc9En+GG6QHOqbkB4NRZ6cwtfwUMhk2FHXBnjF4kAlQMFEDH5
FFukUJAsCdPmTQEBe74EAMBsxDnbD9cuI5MfF/QeTNEG4BIVUZtAkDme4Eg7zvsP
d3DeJKCGeNjiCWYrRTCGwaCWzMQk+/+MOmdkI6Oml+AIurJLoHceHS9jP1izdP7f
N2jkdeJSBsixunbQWtUElSgOQQ4iF5kqwBhxtOfEP/L9QsoydRMR1yB6WPD75H7V
iQCVAwUQMZ9YNGtaZ42Bsqd5AQH0PAQAhpVlAc3ZM/KOTywBSh8zWKVlSk3q/zGn
k7hJmFThnlhH1723+WmXE8aAPJi+VXOWJUFQgwELJ6R8jSU2qvk2m1VWyYSqRKvc
VRQMqT2wjss0GE1Ngg7tMrkRHT0il7E2xxIb8vMrIwmdkbTfYqBUhhGnsWPHZHq7
MoA1/b+rK7CJAJUDBRAxnvXh3IDyptUyfLkBAYTDA/4mEKlIP/EUX2Zmxgrd/JQB
hqcQlkTrBAaDOnOqe/4oewMKR7yaMpztYhJs97i03Vu3fgoLhDspE55ooEeHj0r4
cOdiWfYDsjSFUYSPNVhW4OSruMA3c29ynMqNHD7hpr3rcCPUi7J2RncocOcCjjK2
BQb/9IAUNeK4C9gPxMEZLokAlQMFEDGeO86zWmLrWZ8yPQEBEEID/2fPEUrSX3Yk
j5TJPFZ9MNX0lEo7AHYjnJgEbNI4pYm6C3PnMlsYfCSQDHuXmRQHAOWSdwOLvCkN
F8eDaF3M6u0urgeVJ+KVUnTz2+LZoZs12XSZKCte0HxjbvPpWMTTrYyimGezH79C
mgDVjsHaYOx3EXF0nnDmtXurGioEmW1J
=mSvM
-----END PGP PUBLIC KEY BLOCK-----&a.peter;
Peter Wemm <peter@FreeBSD.org>
aka <peter@spinner.dialix.com>
aka <peter@haywire.dialix.com>
aka <peter@perth.dialix.oz.au>
Key fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/
W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2
kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT
tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMwWT
cXW7bjh2o/exAQEFkQP+LIx5zKlYp1uR24xGApMFNrNtjh+iDIWnxxb2M2Kb6x4G
9z6OmbUCoDTGrX9SSL2Usm2RD0BZfyv9D9QRWC2TSOPkPRqQgIycc11vgbLolJJN
eixqsxlFeKLGEx9eRQCCbo3dQIUjc2yaOe484QamhsK1nL5xpoNWI1P9zIOpDiGJ
AJUDBRAxsRPqSoY3Ydic4xkBAbWLA/9q1Fdnnk4unpGQsG31Qbtr4AzaQD5m/JHI
4gRmSmbj6luJMgNG3fpO06Gd/Z7uxyCJB8pTst2a8C/ljOYZxWT+5uSzkQXeMi5c
YcI1sZbUpkHtmqPW623hr1PB3ZLA1TIcTbQW+NzJsxQ1Pc6XG9fGkT9WXQW3Xhet
AP+juVTAhLQlUGV0ZXIgV2VtbSA8cGV0ZXJAcGVydGguZGlhbGl4Lm96LmF1PokA
lQMFEDGxFCFKhjdh2JzjGQEB6XkD/2HOwfuFrnQUtdwFPUkgtEqNeSr64jQ3Maz8
xgEtbaw/ym1PbhbCk311UWQq4+izZE2xktHTFClJfaMnxVIfboPyuiSF99KHiWnf
/Gspet0S7m/+RXIwZi1qSqvAanxMiA7kKgFSCmchzas8TQcyyXHtn/gl9v0khJkb
/fv3R20btB5QZXRlciBXZW1tIDxwZXRlckBGcmVlQlNELm9yZz6JAJUDBRAxsRJd
SoY3Ydic4xkBAZJUA/4i/NWHz5LIH/R4IF/3V3LleFyMFr5EPFY0/4mcv2v+ju9g
brOEM/xd4LlPrx1XqPeZ74JQ6K9mHR64RhKR7ZJJ9A+12yr5dVqihe911KyLKab9
4qZUHYi36WQu2VtLGnw/t8Jg44fQSzbBF5q9iTzcfNOYhRkSD3BdDrC3llywO7Ql
UGV0ZXIgV2VtbSA8cGV0ZXJAc3Bpbm5lci5kaWFsaXguY29tPokAlQMFEDGxEi1K
hjdh2JzjGQEBdA4EAKmNFlj8RF9HQsoI3UabnvYqAWN5wCwEB4u+Zf8zq6OHic23
TzoK1SPlmSdBE1dXXQGS6aiDkLT+xOdeewNs7nfUIcH/DBjSuklAOJzKliXPQW7E
kuKNwy4eq5bl+j3HB27i+WBXhn6OaNNQY674LGaR41EGq44Wo5ATcIicig/z
=gv+h
-----END PGP PUBLIC KEY BLOCK-----&a.joerg;
Type Bits/KeyID Date User ID
pub 1024/76A3F7B1 1996/04/27 Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Key fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
Joerg Wunsch <joerg_wunsch@interface-business.de>
Joerg Wunsch <j@uriah.heep.sax.de>
Joerg Wunsch <j@interface-business.de>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz
q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe
ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR
tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J
AJUDBRA0FFkBs1pi61mfMj0BAfDCA/oCfkjrhvRwRCpSL8klJ1YDoUJdmw+v4nJc
pw3OpYXbwKOPLClsE7K3KCQscHel7auf91nrekAwbrXv9Clp0TegYeAQNjw5vZ9f
L6UZ5l3fH8E2GGA7+kqgNWs1KxAnG5GdUvJ9viyrWm8dqWRGo+loDWlZ12L2OgAD
fp7jVZTI1okAlQMFEDQPrLoff6kIA1j8vQEB2XQEAK/+SsQPCT/X4RB/PBbxUr28
GpGJMn3AafAaA3plYw3nb4ONbqEw9tJtofAn4UeGraiWw8nHYR2DAzoAjR6OzuX3
TtUV+57BIzrTPHcNkb6h8fPuHU+dFzR+LNoPaGJsFeov6w+Ug6qS9wa5FGDAgaRo
LHSyBxcRVoCbOEaS5S5EiQCVAwUQM5BktWVgqaw0+fnVAQGKPwP+OiWho3Zm2GKp
lEjiZ5zx3y8upzb+r1Qutb08jr2Ewja04hLg0fCrt6Ad3DoVqxe4POghIpmHM4O4
tcW92THQil70CLzfCxtfUc6eDzoP3krD1/Gwpm2hGrmYA9b/ez9+r2vKBbnUhPmC
glx5pf1IzHU9R2XyQz9Xu7FI2baOSZqJAJUDBRAyCIWZdbtuOHaj97EBAVMzA/41
VIph36l+yO9WGKkEB+NYbYOz2W/kyi74kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoL
oAKxE25AoCgl5towqr/sCcu0A0MMvJddUvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zz
xzLIvtcio6kaHd76XxyJpltCASupdD53nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxq
b2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDIIhfR1u244
dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX
+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvckfxvrTgzSzvtYyv1072X3GkVY+SlUMBMA
rdl1qNW23oT7Q558ajnsaL065XJ5m7HacgTTikiofYG8i1s7TrsEeq6PtCJKb2Vy
ZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5zYXguZGU+iQCVAwUQMaS91D4gHQUlG9CZ
AQGYOwQAhPpiobK3d/fz+jWrbQgjkoO+j39glYGXb22+6iuEprFRs/ufKYtjljNT
NK3B4DWSkyIPawcuO4Lotijp6jke2bsjFSSashGWcsJlpnwsv7EeFItT3oWTTTQQ
ItPbtNyLW6M6xB+jLGtaAvJqfOlzgO9BLfHuA2LY+WvbVW447SWJAJUDBRAxqWRs
dbtuOHaj97EBAXDBA/49rzZB5akkTSbt/gNd38OJgC+H8N5da25vV9dD3KoAvXfW
fw7OxIsxvQ/Ab+rJmukrrWxPdsC+1WU1+1rGa4PvJp/VJRDes2awGrn+iO7/cQoS
IVziC27JpcbvjLvLVcBIiy1yT/RvJ+87a3jPRHt3VFGcpFh4KykxxSNiyGygl4kA
lQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJZe5lFkPr2B/Cr7BKMVBot1/JSu05NsHg
JZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDFe/GF0HZD/ZD1FJt8yQjzF2w340B+F2GG
EOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gpkFZrFgg5eON7ikqmusDnOlYStM/CBfgp
SbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokA
lQMFEDHioSdlYKmsNPn51QEByz8D/10uMrwP7MdaXnptd1XNFhpaAPYTVAOcaKlY
OGI/LLR9PiU3FbqXO+7INhaxFjBxa0Tw/p4au5Lq1+Mx81edHniJZNS8tz3I3goi
jIC3+jn2gnVAWnK5UZUTUVUn/JLVk/oSaIJNIMMDaw4J9xPVVkb+Fh1A+XqtPsVa
YESrNp0+iQCVAwUQMwXkzcdm8Q+/vPRJAQEA4QQAgNNX1HFgXrMetDb+w6yEGQDk
JCDAY9b6mA2HNeKLQAhsoZl4HwA1+iuQaCgo3lyFC+1Sf097OUTs74z5X1vCedqV
oFw9CxI3xuctt3pJCbbN68flOlnq0WdYouWWGlFwLlh5PEy//VtwX9lqgsizlhzi
t+fX6BT4BgKi5baDhrWJAJUDBRAyCKveD9eCJxX4hUkBAebMA/9mRPy6K6i7TX2R
jUKSl2p5oYrXPk12Zsw4ijuktslxzQhOCyMSCGK2UEC4UM9MXp1H1JZQxN/DcfnM
7VaUt+Ve0wZ6DC9gBSHJ1hKVxHe5XTj26mIr4rcXNy2XEDMK9QsnBxIAZnBVTjSO
LdhqqSMp3ULLOpBlRL2RYrqi27IXr4kAlQMFEDGpbnd1u244dqP3sQEBJnQD/RVS
Azgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyudZkNkI5zGGDwVneH/cSkKT4OR
ooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8orsQGGWIn5FhqYXsKkjEGxIOBOf
vvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU
=97h7
-----END PGP PUBLIC KEY BLOCK-----
+
+
+ Developers
+
+
+ &a.wosch;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/2B7181AD 1997/08/09 Wolfram Schneider <wosch@FreeBSD.org>
+Fingerprint = CA 16 91 D9 75 33 F1 07 1B F0 B4 9F 3E 95 B6 09
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzPs+aEAAAEEAJqqMm2I9CxWMuHDvuVO/uh0QT0az5ByOktwYLxGXQmqPG1G
+Q3hVuHWYs5Vfm/ARU9CRcVHFyqGQ3LepoRhDHk+JcASHan7ptdFsz7xk1iNNEoe0
+vE2rns38HIbiyQ/2OZd4XsyhFOFtExNoBuyDyNoe3HbHVBQT7TmN/mkrcYGtAAUR
+tCVXb2xmcmFtIFNjaG5laWRlciA8d29zY2hARnJlZUJTRC5vcmc+iQCVAwUQNmrS
+AzmN/mkrcYGtAQFQjAP8CthNueur8XDAZqC5q6NQcDs0PqqQ+raTUfQTv6Km6ykf
+UzdpDlBoRC+CCyHfBfC5zo9N6mB7iV7qS1PljrdIh6VAwHxJN9iopB/x6+nsBvmy
+0YSNt7eyfFrIVegCJvd4ALz5JBV8ZstznOwo8RAhDD0gX58F8nDhgWjy62JekGK0
+IldvbGZyYW0gU2NobmVpZGVyIDx3b3NjaEBhcGZlbC5kZT6JARUDBRA2Z9ZcCMks
+sk6wLt0BAQBICACcTiDZ/AyYWRDLXsBOK+WMRoNk3+bQZ1cdy11nwJo+taT/389M
+0r5TrEJ7CogpXC2rFUExTVWldSFZd8A1YIHtrTsP7YauUH0nA7k0wUnqDRYj8YJR
+eMLFvc1OQ2y+mkvxF2BzzBzh/bcYbgJdWCB1MPahSNQfkGXtp+A5PjEs8Cp4+FLu
+EUFScyxsD3g5/E+0d7mirJpe3pxcf9KCmFGHM89mrTKODQR/7N8dVqa9npeXZotm
+ZK8Jz+tvRKFgNiLf2XL048+IE8ZtJXDYaDzTirHdcAqJMWQuxthCdG3ta4I+w5WM
+WR8JtBLfVNpyU7LN6dl0IB7O5sYhyskApmMwiQCVAwUQM+z5oTmN/mkrcYGtAQGU
+gAP/cJGro/SbV+L19s/Gem26KmegUH+bfIXoh2EzyRJ7heVdybu1LrSDFApmAE7d
+sMDlAA1wd2XjVWD3nIEBl6k+J7qJB4ACjKVGs414jLpdKGPHdLRYqYDj4LyQFMv6
+/BpSoX1gnWp6xlC2xeWRan9ns3XZGS55UBVDvBE/B+fPoTe0JFdvbGZyYW0gU2No
+bmVpZGVyIDxzY2huZWlkZXJAemliLmRlPokAlQMFEDZq0dI5jf5pK3GBrQEB38QD
+/3NYyRPIejtXXq/okdDRyhWmA8cv0KG6gEupKCQKa7ep/OZTw/KxrN3ZOS8zlPod
+tEn8mol+4SvY5AgSMdjQ0jTd1JdFcMKFnbJJrJ3b9IpwCqbkXy25rTUcQn9ICP47
+rFKC4qR/Ucrg5YVVhQ3pVJX6XuO2XvuG7euHAQNXV3e2
+=EpJQ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
+
+ &a.brian;
+
+
+Type Bits/KeyID Date User ID
+pub 1024/666A7421 1997/04/30 Brian Somers <brian@Awfulhak.org>
+ Key fingerprint = 2D 91 BD C2 94 2C 46 8F 8F 09 C4 FC AD 12 3B 21
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: 2.6.3ia
+
+mQCNAzNmogUAAAEEALdsjVsV2dzO8UU4EEo7z3nYuvB2Q6YJ8sBUYjB8/vfR5oZ9
+7aEQjgY5//pXvS30rHUB9ghk4kIFSljzeMudE0K2zH5n2sxpLbBKWZRDLS7xnrDC
+I3j9CNKwQBzMPs0fUT46gp96nf1X8wPiJXkDUEia/c0bRbXlLw7tvOdmanQhAAUR
+tCFCcmlhbiBTb21lcnMgPGJyaWFuQGF3ZnVsaGFrLm9yZz6JAJUDBRAzbedc77Ox
+BWZTbW0BAVtFA/42QelA3RBXYUtIcYGob+QsWkA1kGyBKQGPSS9coHdUVjClBRl3
+UZFmZhxAODb7cBRXmpvx2ZuMrhn/MpXTMqPOJaE3FYm+5SoeArphsRU+T8XofxfL
+vRHkM3JURUjIVZdAQNvxxBso8NJG5KayP0Q96Vw+3sEwFK49jt14RCJy4IkAlQMF
+EDNzvb1sq+iWcxFJBQEBfZwD/R3KNFf9ype9Dea8j1YIeNZ1E3e03en1I8fMj6Em
+S1/L1WfFzMnfFCxZs7JgPtkBuB3CqP8f+LOdDt6PHPqNakmI9E6fiuGfJZ3jFZYA
+TXa0XKuIoxIJNKhqkpbF8ixJZFTxFwAAwVYM3+sqr4qQ8FzVc5entxjyxPFNkwJw
+RWV+iQCVAwUQM2aiBQ7tvOdmanQhAQE7LgQAiN6Hz+zd8bh0nO6VizbJxWFRHPbr
+QWnJXGoMYyy88DyszAXC4zRshlyGUDQdHeP/1DFCXDEu78GfDCLaJ1bm25yVR7kL
+xDZaEUQEbWqxfiwuzizAjkaxrW7dBbWILwWqrYF5TXClw+oUU/oIUW4t6t+GpAO1
+8PLYhSMXVYErrAA=
+=EdyZ
+-----END PGP PUBLIC KEY BLOCK-----
+
+
diff --git a/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml b/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml
index 092d021ad9..59c780838e 100644
--- a/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml
@@ -1,4523 +1,4673 @@
Installing Applications: The Ports collectionContributed by &a.jraynard;.The FreeBSD Ports collection allows you to compile and install a
very wide range of applications with a minimum of effort.For all the hype about open standards, getting a program to work
on different versions of Unix in the real world can be a tedious and
tricky business, as anyone who has tried it will know. You may be
lucky enough to find that the program you want will compile cleanly on
your system, install itself in all the right places and run flawlessly
“out of the box”, but this is unfortunately rather rare. With most
programs, you will find yourself doing a fair bit of head-scratching,
and there are quite a few programs that will result in premature
greying, or even chronic alopecia...Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but
they have an unfortunate tendency to triumphantly announce that your
system is something you have never heard of and then ask you lots of
questions that sound like a final exam in system-level Unix
programming (Does your system's gethitlist function return a const
pointer to a fromboz or a pointer to a const fromboz? Do you have
Foonix style unacceptable exception handling? And if not, why
not?).Fortunately, with the Ports collection, all the hard work
involved has already been done, and you can just type make install
and get a working program.Why Have a Ports Collection?The base FreeBSD system comes with a very wide range of tools
and system utilities, but a lot of popular programs are not in the
base system, for good reasons:-Programs that some people cannot live without and other
people cannot stand, such as a certain Lisp-based editor.Programs which are too specialised to put in the base
system (CAD, databases).Programs which fall into the “I must have a look at that
when I get a spare minute” category, rather than
system-critical ones (some languages, perhaps).Programs that are far too much fun to be supplied with a
serious operating system like FreeBSD ;-)However many programs you put in the base system, people
will always want more, and a line has to be drawn somewhere
(otherwise FreeBSD distributions would become absolutely
enormous).Obviously it would be unreasonable to expect everyone to port
their favourite programs by hand (not to mention a tremendous amount
of duplicated work), so the FreeBSD Project came up with an
ingenious way of using standard tools that would automate the
process.Incidentally, this is an excellent illustration of how “the
Unix way” works in practice by combining a set of simple but very
flexible tools into something very powerful.How Does the Ports Collection Work?Programs are typically distributed on the Internet as a
tarball consisting of a
Makefile and the source code for the program and usually some
instructions (which are unfortunately not always as instructive as
they could be), with perhaps a configuration script.The standard scenario is that you FTP down the tarball, extract
it somewhere, glance through the instructions, make any changes
that seem necessary, run the configure script to set things up and
use the standard make program to compile and install the program
from the source.FreeBSD ports still use the tarball mechanism, but use a
skeleton to hold the
"knowledge" of how to get the program working on FreeBSD,
rather than expecting the user to be able to work it out. They also
supply their own customised
Makefile, so that almost
every port can be built in the same way.If you look at a port skeleton (either on your FreeBSD
system or the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about Getting a port).“How on earth can this do anything?” I hear you cry. “There
is no source code there!”Fear not, gentle reader, all will become clear (hopefully).
Let's see what happens if we try and install a port. I have chosen
ElectricFence, a useful tool for developers, as the skeleton is
more straightforward than most.If you are trying this at home, you
will need to be root.&prompt.root; cd /usr/ports/devel/ElectricFence
&prompt.root; make install
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
===> Extracting for ElectricFence-2.0.5
===> Patching for ElectricFence-2.0.5
===> Applying FreeBSD patches for ElectricFence-2.0.5
===> Configuring for ElectricFence-2.0.5
===> Building for ElectricFence-2.0.5
[lots of compiler output...]
===> Installing for ElectricFence-2.0.5
===> Warning: your umask is "0002". If this is not desired, set it to
an appropriate value and install this port again by ``make reinstall''.
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
===> Compressing manual pages for ElectricFence-2.0.5
===> Registering installation for ElectricFence-2.0.5To avoid confusing the issue, I have completely removed the
build output.If you tried this yourself, you may well have got something like
this at the start:-&prompt.root; make install
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.The make program has noticed that you did not have a local
copy of the source code and tried to FTP it down so it could get the
job done. I already had the source handy in my example, so it did
not need to fetch it.Let's go through this and see what the make program was
doing.Locate the source code tarball. If it is not available locally, try to
grab it from an FTP site.Run a checksum
test on the tarball to make sure it has not been tampered
with, accidentally truncated, downloaded in ASCII mode, struck
by neutrinos while in transit, etc.Extract the tarball into a temporary work directory.Apply any patches
needed to get the source to compile and run under FreeBSD.Run any configuration script required by the build
process and correctly answer any questions it asks.(Finally!) Compile the code.Install the program executable and other supporting
files, man pages, etc. under the
/usr/local hierarchy, where they will not
get mixed up with system programs. This also makes sure that
all the ports you install will go in the same place, instead
of being flung all over your system.Register the installation in a database. This means that,
if you do not like the program, you can cleanly remove all traces of it from
your system.Scroll up to the make output and see if you can match these
steps to it. And if you were not impressed before, you should be by
now!Getting a FreeBSD PortThere are two ways of getting hold of the FreeBSD port for a
program. One requires a FreeBSD
CDROM, the other involves using an Internet Connection.Compiling ports from CDROMAssuming that your FreeBSD CDROM is in the drive and mounted on
/cdrom (and the mount point
must be /cdrom), you should
then be able to build ports just as you normally do and the port
collection's built in search path should find the tarballs in
/cdrom/ports/distfiles/ (if they exist there)
rather than downloading them over the net.
-
+
+ Another way of doing this, if you want to just use the port
+ skeletons on the CDROM, is to set these variables in
+ /etc/make.conf:
+
+
+PORTSDIR= /cdrom/ports
+DISTDIR= /tmp/distfiles
+WRKDIRPREFIX= /tmp
+
+ Substitute /tmp for any place you have enough
+ free space. Then, just cd to the appropriate
+ subdirectory under /cdrom/ports and type
+ make install as
+ usual. WRKDIRPREFIX will cause the port to be
+ build under /tmp/cdrom/ports; for instance,
+ games/oneko will be built under
+ /tmp/cdrom/ports/games/oneko.
+
There are some ports for which we cannot provide the
original source in the CDROM due to licensing limitations. In
that case, you will need to look at the section on Compiling ports using an Internet connection.Compiling ports from the InternetIf you do not have a CDROM, or you want to make sure you get
the very latest version of the port you want, you will need to
download the
skeleton for the port. Now
this might sound like rather a fiddly job full of pitfalls, but
it is actually very easy.First, if you are running a release version of FreeBSD, make
sure you get the appropriate “upgradekiet” for your
replease from the ports
web page. These packages include files that have been
updated since the release that you may need to compile new
ports.The key to the skeletons is that the FreeBSD FTP server can create
on-the-fly
tarballs for you. Here is
how it works, with the gnats program in the databases directory as
an example (the bits in square brackets are comments. Do not type
them in if you are trying this yourself!):-&prompt.root; cd /usr/ports
&prompt.root; mkdir databases
&prompt.root; cd databases
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports/databases
+>cd /pub/FreeBSD/ports/ports/databases>get gnats.tar
[tars up the gnats skeleton for us]
>quit
&prompt.root; tar xf gnats.tar
[extract the gnats skeleton]
&prompt.root; cd gnats
&prompt.root; make install
[build and install gnats]What happened here? We connected to the FTP server in the
usual way and went to its databases sub-directory. When we gave it
the command get gnats.tar, the FTP server tarred up the gnats directory for us.We then extracted the gnats skeleton and went into the gnats
directory to build the port. As we explained earlier, the make process noticed we did not have a
copy of the source locally, so it fetched one before extracting,
patching and building it.Let's try something more ambitious now. Instead of getting a
single port skeleton, let's get a whole sub-directory, for example
all the database skeletons in the ports collection. It looks
almost the same:-&prompt.root; cd /usr/ports
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports
+>cd /pub/FreeBSD/ports/ports>get databases.tar
[tars up the databases directory for us]
>quit
&prompt.root; tar xf databases.tar
[extract all the database skeletons]
&prompt.root; cd databases
&prompt.root; make install
[build and install all the database ports]With half a dozen straightforward commands, we have now got a
set of database programs on our FreeBSD machine! All we did that
was different from getting a single port skeleton and building it
was that we got a whole directory at once, and compiled everything
in it at once. Pretty impressive, no?If you expect to be installing many ports, it is probably
worth downloading all the ports directories.SkeletonsA team of compulsive hackers who have forgotten to eat in a
frantic attempt to make a deadline? Something unpleasant lurking in
the FreeBSD attic? No, a skeleton here is a minimal framework that
supplies everything needed to make the ports magic work.MakefileThe most important component of a skeleton is the Makefile.
This contains various statements that specify how the port should
be compiled and installed. Here is the Makefile for
ElectricFence:-
# New ports collection makefile for: Electric Fence
# Version required: 2.0.5
# Date created: 13 November 1997
# Whom: jraynard
#
# $Id$
#
DISTNAME= ElectricFence-2.0.5
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SUNSITE}
MASTER_SITE_SUBDIR= devel/lang/c
MAINTAINER= jraynard@freebsd.org
MAN3= libefence.3
do-install:
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
.include <bsd.port.mk>The lines beginning with a "#" sign are comments for
the benefit of human readers (as in most Unix script
files).DISTNAME specifies the name of the tarball, but without the
extension.CATEGORIES states what kind of program this is. In
this case, a utility for developers. See the categories section of this
handbook for a complete list.MASTER_SITES is the URL(s) of the master FTP site,
which is used to retrieve the tarball if it is not available on the local system.
This is a site which is regarded as reputable, and is normally the
one from which the program is officially distributed (in so far
as any software is "officially" distributed on the
Internet).MAINTAINER is the email address of the person who is
responsible for updating the skeleton if, for example a new
version of the program comes out.Skipping over the next few lines for a minute, the line
.include <bsd.port.mk> says
that the other statements and commands needed for this port are
in a standard file called bsd.port.mk. As
these are the same for all ports, there is no point in duplicating
them all over the place, so they are kept in a single standard
file.This is probably not the place to go into a detailed
examination of how Makefiles work; suffice it to say that the line
starting with MAN3 ensures that the ElectricFence man page is
compressed after installation, to help conserve your precious disk
space. The original port did not provide an install target,
so the three lines from do-install ensure that the files
produced by this port are placed in the correct
destination.The files directoryThe file containing the checksum for the port is called
md5, after the MD5 algorithm used for ports
checksums. It lives in a directory with the slightly confusing
name of files.This directory can also contain other miscellaneous files that
are required by the port and do not belong anywhere else.The patches directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The pkg directoryThis program contains three quite useful files:-COMMENT — a one-line description of
the program.DESCR — a more detailed description.PLIST — a list of all the files
that will be created when the program is installed.What to do when a port does not work.Oh. You can do one of four (4) things :Fix it yourself. Technical details on how ports work can
be found in
Porting applications.Gripe. This is done by e-mail only! Send such e-mail to
the &a.ports; and please include the name/version of the port,
where you got both the port source & distfile(s) from, and
what the text of the error was.Forget it. This is the easiest for most — very few of the
programs in ports can be classified as essential!Grab the pre-compiled package from a ftp server. The
“master” package collection is on FreeBSD's FTP server in
the packages
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/">packages
directory, though check your local mirror first,
please! These are more likely to work (on the whole) than
trying to compile from source and a lot faster besides! Use
the pkg_add1 program to install a
package file on your system.Some Questions and AnswersQ. I thought this was going to be a discussion about
modems??!A. Ah. You must be thinking of the serial ports on the
back of your computer. We are using “port” here to mean the
result of “porting” a program from one version of Unix to
another. (It is an unfortunate bad habit of computer people to
use the same word to refer to several completely different
things).Q. I thought you were supposed to use packages to install
extra programs?A. Yes, that is usually the quickest and easiest way of
doing it.Q. So why bother with ports then?A. Several reasons:-The licensing conditions on some software
distributions require that they be distributed as source
code, not binaries.Some people do not trust binary distributions. At
least with source code you can (in theory) read through
it and look for potential problems yourself.If you have some local patches, you will need the
source to add them yourself.You might have opinions on how a program should be
compiled that differ from the person who did the package
— some people have strong views on what optimisation
setting should be used, whether to build debug versions
and then strip them or not, etc. etc.Some people like having code around, so they can
read it if they get bored, hack around with it, borrow
from it (licence terms permitting, of course!) and so
on.If you ain't got the source, it ain't software!
;-) Q. What is a patch?A. A patch is a small (usually) file that specifies how to
go from one version of a file to another. It contains text
that says, in effect, things like “delete line 23”, “add
these two lines after line 468” or “change line 197 to
this”. Also known as a “diff”, since it is generated by a
program of that name. Q. What is all this about
tarballs?A. It is a file ending in .tar or
.tar.gz (with variations like
.tar.Z, or even .tgz
if you are trying to squeeze the names into a DOS
filesystem).Basically, it is a directory tree that has been archived
into a single file (.tar) and optionally
compressed (.gz). This technique was
originally used for Tape
ARchives (hence the name tar), but it is
a widely used way of distributing program source code around
the Internet.You can see what files are in them, or even extract them
yourself, by using the standard Unix tar program, which comes
with the base FreeBSD system, like this:-&prompt.user; tar tvzf foobar.tar.gz
&prompt.user; tar xzvf foobar.tar.gz
&prompt.user; tar tvf foobar.tar
&prompt.user; tar xvf foobar.tar Q. And a checksum?A. It is a number generated by adding up all the data in
the file you want to check. If any of the characters change,
the checksum will no longer be equal to the total, so a simple
comparison will allow you to spot the difference. (In
practice, it is done in a more complicated way to spot
problems like position-swapping, which will not show up with a
simplistic addition).Q. I did what you said for compiling ports from a CDROM and it worked great
until I tried to install the kermit port:-&prompt.root; make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.Why can it not be found? Have I got a dud CDROM?A. The licensing terms for kermit do not allow us to put
the tarball for it on the CDROM, so you will have to fetch it
by hand — sorry! The reason why you got all those error
messages was because you were not connected to the Internet at
the time. Once you have downloaded it from any of the sites
above, you can re-start the process (try and choose the
nearest site to you, though, to save your time and the
Internet's bandwidth).Q. I did that, but when I tried to put it into
/usr/ports/distfiles I got some error
about not having permission.A. The ports mechanism looks for the tarball in
/usr/ports/distfiles, but you will not be
able to copy anything there because it is sym-linked to the
CDROM, which is read-only. You can tell it to look somewhere
else by doing&prompt.root; make DISTDIR=/where/you/put/it installQ. Does the ports scheme only work if you have everything
in /usr/ports? My system administrator
says I must put everything under
/u/people/guests/wurzburger, but it does
not seem to work.A. You can use the PORTSDIR and PREFIX variables to tell
the ports mechanism to use different directories. For
instance,&prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports installwill compile the port in
/u/people/guests/wurzburger/ports and
install everything under /usr/local.&prompt.root; make PREFIX=/u/people/guests/wurzburger/local installwill compile it in /usr/ports and
install it in
/u/people/guests/wurzburger/local.And of course&prompt.root; make PORTSDIR=.../ports PREFIX=.../local installwill combine the two (it is too long to fit on the page if
I write it in full, but I am sure you get the idea).If you do not fancy typing all that in every time you
install a port (and to be honest, who would?), it is a good
idea to put these variables into your environment.Q. I do not have a FreeBSD CDROM, but I would like to have
all the tarballs handy on my system so I do not have to wait
for a download every time I install a port. Is there an easy
way to get them all at once?A. To get every single tarball for the ports collection,
do&prompt.root; cd /usr/ports
&prompt.root; make fetchFor all the tarballs for a single ports directory,
do&prompt.root; cd /usr/ports/directory
&prompt.root; make fetchand for just one port — well, I think you have guessed
already.Q. I know it is probably faster to fetch the tarballs from
one of the FreeBSD mirror sites close by. Is there any way to
tell the port to fetch them from servers other than ones
listed in the MASTER_SITES?A. Yes. If you know, for example, ftp.FreeBSD.ORG is much
closer than sites listed in MASTER_SITES, do as following
example.&prompt.root; cd /usr/ports/directory
-&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
+&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetchQ. I want to know what files make is going to need before
it tries to pull them down.A. make fetch-list will display a list of the files
needed for a port.Q. Is there any way to stop the port from compiling? I
want to do some hacking on the source before I install it, but
it is a bit tiresome having to watch it and hit control-C
every time.A. Doing make extract will stop it after it has fetched
and extracted the source code.Q. I am trying to make my own port and I want to be able
to stop it compiling until I have had a chance to see if my
patches worked properly. Is there something like make
extract, but for patches?A. Yep, make patch is what you want. You will probably
find the PATCH_DEBUG option useful as well. And by the way,
thank you for your efforts!Q. I have heard that some compiler options can cause bugs.
Is this true? How can I make sure that I compile ports with
the right settings?A. Yes, with version 2.6.3 of gcc (the version shipped
with FreeBSD 2.1.0 and 2.1.5), the option could result in
buggy code unless you used the option as
well. (Most of the ports don't use ). You
should be able to specify the compiler
options used by something like&prompt.root; make CFLAGS='-O2 -fno-strength-reduce' installor by editing /etc/make.conf, but
unfortunately not all ports respect this. The surest way is to
do make configure, then go into the source directory and
inspect the Makefiles by hand, but this can get tedious if the
source has lots of sub-directories, each with their own
Makefiles.Q. There are so many ports it is hard to find the one I
want. Is there a list anywhere of what ports are available?A. Look in the INDEX file in
/usr/ports. If you would like to search the
ports collection for a keyword, you can do that too. For example,
you can find ports relevant to the LISP programming language
using:&prompt.user; cd /usr/ports
&prompt.user; make search key=lispQ. I went to install the foo port but the system
suddenly stopped compiling it and starting compiling the
bar
port. What's going on?A. The foo port needs something that is supplied with
bar — for instance, if foo uses graphics, bar might have
a library with useful graphics processing routines. Or bar
might be a tool that is needed to compile the foo
port. Q. I installed the grizzle
program from the ports and frankly it is a complete waste of
disk space. I want to delete it but I do not know where it put
all the files. Any clues?A. No problem, just do&prompt.root; pkg_delete grizzle-6.5
Q. Hang on a minute, you have to know the version number to
use that command. You do not seriously expect me to remember
that, do you??A. Not at all, you can find it out by doing&prompt.root; pkg_info -a | grep grizzle
Information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.Q. Talking of disk space, the ports directory seems to be
taking up an awful lot of room. Is it safe to go in there and
delete things?A. Yes, if you have installed the program and are fairly
certain you will not need the source again, there is no point
in keeping it hanging around. The best way to do this
is&prompt.root; cd /usr/ports
&prompt.root; make cleanwhich will go through all the ports subdirectories and
delete everything except the skeletons for each port.Q. I tried that and it still left all those tarballs or
whatever you called them in the distfiles
directory. Can I delete those as well?A. Yes, if you are sure you have finished with them, those
can go as well.Q. I like having lots and lots of programs to play with.
Is there any way of installing all the ports in one go?A. Just do&prompt.root; cd /usr/ports
&prompt.root; make installQ. OK, I tried that, but I thought it would take a very
long time so I went to bed and left it to get on with it. When
I looked at the computer this morning, it had only done three
and a half ports. Did something go wrong?A. No, the problem is that some of the ports need to ask
you questions that we cannot answer for you (eg “Do you want
to print on A4 or US letter sized paper?”) and they need to
have someone on hand to answer them.Q. I really do not want to spend all day staring at the
monitor. Any better ideas?A. OK, do this before you go to bed/work/the local
park:-&prompt.root cd /usr/ports
&prompt.root; make -DBATCH installThis will install every port that does
not require user input. Then, when you
come back, do&prompt.root; cd /usr/ports
&prompt.root; make -DIS_INTERACTIVE installto finish the job.Q. At work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do
what we need. Is there any way of making our own packages, so
we can distribute it more easily around our sites?A. No problem, assuming you know how to make patches for
your changes:-&prompt.root; cd /usr/ports/somewhere/frobble
&prompt.root; make extract
&prompt.root; cd work/frobble-2.8
[Apply your patches]
&prompt.root; cd ../..
&prompt.root; make packageQ. This ports stuff is really clever. I am desperate to
find out how you did it. What is the secret?A. Nothing secret about it at all, just look at the
bsd.ports.mk and
bsd.ports.subdir.mk files in your makefiles
directory.Readers with an aversion to intricate shell-scripts are
advised not to follow this link...)Making a port yourselfContributed by &a.jkh;, &a.gpalmer;, &a.asami;
&a.obrien; and &a.hoek;. 28 August 1996.So, now you are interested in making your own port?
Great!What follows are some guidelines for creating a new port for
FreeBSD. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Only a fraction of the overridable variables
(VAR) are mentioned
in this document. Most (if not all) are documented at the start of
bsd.port.mk. This file users a non-standard
tab setting. Emacs and
Vim should recognise the setting on
loading the file. vi or ex
can be set to use the correct value by typing :set
tabstop=4 once the file has been loaded.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into DISTDIR, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the MakefileThe minimal Makefile would
look something like this:
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# $Id$
#
DISTNAME= oneko-1.1b
CATEGORIES= games
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG
MAN1= oneko.1
MANCOMPRESSED= yes
USE_IMAKE= yes
.include <bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the sample Makefile
section.Writing the description filesThere are three description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.COMMENTThis is the one-line description of the port.
Please do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the screen.DESCRThis is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual or an
in-depth description on how to use or compile the port!
Please be careful if you are copying from the
README or manpage; too often
they are not a concise description of the port or are in an
awkward format (e.g., manpages have justified spacing). If the
ported software has an official WWW homepage, you should list
it here.It is recommended that you sign the name at the end of
this file, as in:
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
http://www.oneko.org/
- Satoshi
asami@cs.berkeley.eduPLISTThis file lists all the files installed by the port. It
is also called the “packing list” because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). If you are using the
MANn variables (as
you should be), do not list any manpages here.Here is a small example:
bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/onekoRefer to the pkg_create1 man page
for details on the packing list.You should list all the files, but not the name
directories, in the list. Also, if the port creates
directories for itself during installtion, make sure to add
@dirrm lines as necessary to remove them
when the port is deleted.It is recommended that you keep all the filenames in
this file sorted alphabetically. It will make verifying the
changes when you upgrade the port much easier.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. These are
the important points you need to verify.PLIST does not contain anything not
installed by your portPLIST contains everything that is
installed by your portYour port can be installed multiple times using the
reinstall targetYour port cleans
up after itself upon deinstallRecommended test orderingmake installmake packagemake deinstallpkg_add `make package-name`make deinstallmake reinstallmake packageMake sure that there aren't any warnings issued in any of
the package and
deinstall stages, After step 3, check
to see if all the new directories are correctly deleted. Also,
try using the software after step 4, to ensure that is works
correctly when installed from a package.Checking your port with portlintPlease use portlint to see if your port
conforms to our guidelines. The portlint
program is part of the ports collection. In particular, your may
want to check if the Makefile is in the right
shape and the package is
named appropriately.Submitting the portFirst, make sure you have read the Do's and Dont's section.Now that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. We do not need your
work directory or the
pkgname.tgz package, so delete them
now. Next, simply include the output of shar `find
port_dir` in a bug report and send it with the
send-pr1 program (see Bug
Reports and General Commentary for more information
about send-pr1. If the uncompressed port is larger than
20KB, you should compress it into a tarfile and use uuencode1 before including it in the bug report (uuencoded
tarfiles are acceptable even if the bug report is smaller than
20KB but are not preferred). Be sure to classify the bug report as
category ports and class
change-request. (Do not mark the report
confidential!)One more time, do not include the original source
distfile, the work directory, or the
package you built with make
package.In the past, we asked you to upload new port submissions
in our ftp site (ftp.freebsd.org). This is no longer
recommended as read access is turned off on that
incoming/ directory of that site due to
the large amount of pirated software showing up there.We will look at your port,
get back to you if necessary, and put it in the
tree. Your name will also appear in the list of “Additional
FreeBSD contributors” on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in DISTDIR.
If fetch cannot find the required files in DISTDIR it will look up the
URL MASTER_SITES,
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
The extract target is run. It looks for your port's
distribution file (typically a gzip'd tarball) in DISTDIR and unpacks it into a temporary subdirectory
specified by WRKDIR
(defaults to work).The patch target is run. First, any patches defined
in PATCHFILES are
applied. Second, if any patches are found in PATCHDIR (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.The configure target is run. This can do any one of
many different things.If it exists,
scripts/configure is run.If HAS_CONFIGURE or
GNU_CONFIGURE
is set,
WRKSRC/configure is
run.If USE_IMAKE is set,
XMKMF
(default: xmkmf
-a) is run.The build target is run. This is responsible for
- descending into the ports' private working directory
+ descending into the port's private working directory
(WRKSRC) and
building it. If USE_GMAKE is set, GNU
make will be used,
otherwise the system make
will be used.The above are the default actions. In addition, you can
define targets pre-something or post-something, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-something. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-something target in
your Makefile.The “main” targets (e.g., extract, configure, etc.) do nothing more than
- make sure all the stages up to that one is completed and
+ make sure all the stages up to that one are completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (foo.tar.gz or
foo.tar.Z) and copy it into
DISTDIR. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, you might want to put a copy on a
reliable ftp or http server that you control (e.g., your home
page). Make sure you set MASTER_SITES to
reflect your choice.If you
cannot find somewhere convenient and reliable to put the distfile
(if you are a FreeBSD committer, you can just put it in your
public_html/ directory on
freefall),
we can “house” it ourselves by putting
- it on ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
+ it on ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as MASTER_SITE_LOCAL. Send mail to
the &a.ports;if you are not sure what to do.If your port's distfile changes all the time for no good
reason, consider putting the distfile in your home page and
listing it as the first MASTER_SITES. This
will prevent users from getting checksum
mismatch errors, and also reduce the workload of
maintainers of our ftp site. Also, if there isonly one master
site for the port, it is recommended that you house a backup at
your site and list it as the second
MASTER_SITES.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
DISTDIR. Do not worry if
- they come from site other than where you got the main source
+ they come from a site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of PATCHFILES below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as “plug-and-play”
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-xx where
xx denotes the sequence in which
the patches will be applied — these are done in
alphabetical order, thus
aa first, ab second and so on. These files
should be stored in PATCHDIR, from where they will be
automatically applied. All patches should be relative to
WRKSRC (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier,
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing WRKSRC/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow “overnight builds” to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).It is also recommended that if there are reasonable default
answers to the questions, you check the
PACKAGE_BUILDING variable and turn off the
interactive script when it is set. This will allow us to build
the packages for CD-ROMs and ftp.Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a sample
Makefile in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in DISTDIR as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set DISTNAME to be the base name of
your port. The default rules expect the distribution file
list (DISTFILES) to be
named DISTNAMEEXTRACT_SUFX which, if it is a normal tarball, is going to be
something like foozolix-1.0.tar.gz for a setting of DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/DISTNAME, e.g. work/foozolix-1.0/.All this behavior can be overridden, of course; it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set DISTFILES explicitly. If only a
subset of DISTFILES are
actual extractable archives, then set them up in EXTRACT_ONLY, which will override
the DISTFILES list when
it comes to extraction, and the rest will be just left in
DISTDIR for later
use.PKGNAMEIf DISTNAME does not conform to our guidelines for a good package
name, you should set the PKGNAME
variable to something better. See the abovementioned guidelines
for more details.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable CATEGORIES. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories and pick the
ones that are suitable for your port.This list also determines where in the ports tree the port
is imported. If you put more than one category here, it is
assumed that the port files will be put in the subdirectory with
the name in the first category. See the categories section for
more discussion about how to pick the right categories.If you port truly belongs to something that is different
from all the existing ones, you can even create a new category
name. In that case, please send mail to the &a.ports; to propose
a new category.There is no error checking for category
names. make package will happily create a
new directory if you mustype the category name, so be
careful!MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in MASTER_SITES. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with FETCH if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set PATCHFILES to the names of the
files and PATCH_SITES to
the URL of the directory that contains them (the format is the
same as MASTER_SITES).If the patch is not relative to the top of the source tree
(i.e., WKRSRC) because it
contains some extra pathnames, set PATCH_DIST_STRIP accordingly.
- For instance, if all the pathnames in the patch has an extra
+ For instance, if all the pathnames in the patch have an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
PATCHFILES. If that is
the case, add the name and the location of the patch tarball
to DISTFILES and
MASTER_SITES. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the PATCHDIR directory and calling it
patch-xx.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to MAINTAINER
on Makefiles section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine. There are also some
pre-supported dependency variables for common cases, plus a few
more to control the behaviour of dependencies.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir:target tuples where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available, and
target is the target to call in
that directory. For example,
LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install
will check for a shared jpeg library with
major version 9, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found. The target part can be
omitted if it is equal to DEPENDS_TARGET
(which defaults to install).The lib part is an argument
given to ldconfig -r | grep -wF. There
shall be no reqular expressions in this variable.The dependency is checked twice, once from within the
extract target and then from within
the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir:target tuples where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available, and
target is the target to call in
that directory. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
will check if the file or directory
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish8.0 is in your search path, and
descend into the x11-toolkits/tk80 subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system. The
target part can be omitted if it is
the same DEPENDS_TARGET.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir:target tuples.
For example,
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.“build” here means everything from extracting to
compilation. The dependency is checked from within the
extract target. The
target part can be omitted if it
is the same as DEPENDS_TARGETFETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir:target tuples. For
example,
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the
fetch target. The
target part can be omitted if it is
the same as DEPENDS_TARGET.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted in addition to having
them installed, then use this variable. This is a list of
dir:target, as there is nothing to check, unlike the previous four. The target part can be omitted if it is the same as DEPENDS_TARGET.Common dependency variablesDefine USE_XLIB=yes if your port
requires the X Window System to be installed (it is implied by
USE_IMAKE). Define
USE_GMAKE=yes if your port requires GNU
make instead of BSD
make. Define
USE_AUTOCONF=yes if your port requires GNU
autoconf to be run. Define USE_QT=yes if
your port uses the latest qt toolkit. Use
USE_PERL5=yes if your port requires version
5 of the perl language. (The last is especially important since
some versions of FreeBSD has perl5 as part of the base system
while others don't.)Notes on dependenciesAs mentioned above, the default target to call when a
dependency is required is
DEPENDS_TARGET. It defaults to
install. This is a user variable; is is
never defined in a port's Makefile. If
your port needs a special way to handle a dependency, use the
:target part of the
*_DEPENDS variables instead of redefining
DEPENDS_TARGET.When you type make clean, its
dependencies are automatically cleaned too. If you do not wish
this to happen, define the variable
NOCLEANDEPENDS in your environment.To depend on another port unconditionally, it is customary
to use the string nonexistent as the first
field of BUILD_DEPENDS or
RUN_DEPENDS. Use this only when you need to
the to get to the source of the other port. You can often save
compilation time by specifying the target too. For
instance
BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract
will always descend to the JPEG port and extract it.Do not use DEPENDS unless there is no
other way the behaviour you want can be accomplished. It will
cause the other port to be always build (and installed, by
default), and the dependency will go into the packages as
- well. If this is really what you need, I recommend you to
+ well. If this is really what you need, I recommend you
write it as BUILD_DEPENDS and
RUN_DEPENDS instead—at least the
intention will be clear.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses
configure, set
HAS_CONFIGURE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes (this implies
HAS_CONFIGURE). If you want to give some
extra arguments to configure (the default
argument list --prefix=${PREFIX} for
GNU configure and empty for non-GNU
configure), set those extra arguments in
CONFIGURE_ARGS. If your package uses GNU
autoconf, set
USE_AUTOCONF=yes. This implies
GNU_CONFIGURE, and will cause
autoconf to be run before
configure.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.
If the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>If your port's source Makefile has
something else than all as the main
build target, set ALL_TARGET
accordingly. Same goes for install and
INSTALL_TARGET.Special considerationsThere are some more things you have to take into account when
you create a port. This section explains the most common of
those.ldconfigIf your port installs a shared library, add a
post-install target to your
Makefile that runs
${LDCONFIG} -m on the directory where
the new library is installed (usually
PREFIX/lib) to register
it into the shared library cache.Also, add a matching @exec /sbin/ldconfig
-m and @unexec /sbin/ldconfig -R
pair to your pkg/PLIST file so that a user
who installed the package can start using teh shared libraru
immediately and deinstallation will not cause the system to
still believe the library is there. These lines should
immediately follow the line for the shared library itself, as
in:
lib/libtvl80.so.1
@exec /sbin/ldconfig -m %D/lib
@unexec /sbin/ldconfig -RNever, ever, ever add a line that says
ldconfig without any arguments to your
Makefile or
pkg/PLIST. This will reset the shared
libraru cache to the contents of /usr/lib
only, and will royally screw up the user's machine ("Help, xinit
does not run anymore after I install this port!"). Anybody who
does this will be shot and cut in 65,536 pieces by a rusty knife
and have is liver chopped out by a bunch of crows and will
eternally rot to death in the deepest bowels of hell (not
necessarily in that order…)ELF support
- Since FreeBSD is moving to ELF from 3.0-release onwards,
+ Since FreeBSD is moving to ELF shortly after 3.0-release,
we need to convert many ports that build shared libraries
to support ELF. Complicating this task is that a 3.0
system can run as both ELF and a.out, and that there will
be one more release (2.2.8) from the 2.2 branch. Below
are the guidelines on how to convert a.out only ports to
support both a.out and ELF compilation.Some part of this list is only applicable during the
conversion, but will be left here for awhile for reference
in case you have come across some old port you wish to
upgrade.Moving a.out libraries out of the wayA.out libraries should be moved out of
/usr/local/lib and similar to an
aout subdirectory. (If you don't move them
out of the way, ELF ports will happily overwrite a.out libraries.)
The move-aout-libs target in the -current
src/Makefile (called from
aout-to-elf) will do this for you. It
will only move a.out libs so it is safe to call it on a system
with both ELF and a.out libs in the standard directories.FormatThe ports tree will build packages in the format the machine
is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending
on what `objformat` returns. Also, once users
move a.out libraries to a subdirectory, building a.out libraries
will be unsupported. (I.e., it may still work if you know what you
are doing, but you are on your own.)If a port only works for a.out, set
BROKEN_ELF to a string describing the reason
why. Such ports will be skipped during a build on an ELF
system.PORTOBJFORMATbsd.port.mk will set
PORTOBJFORMAT to aout or
elf and export it in the environments
CONFIGURE_ENV, SCRIPTS_ENV and
MAKE_ENV. (It's always going to be
aout in -stable). It is also passed to
PLIST_SUB as
PORTOBJFORMAT=${PORTOBJFORMAT}. (See comment
on ldconfig lines below.)The variable is set using this line in
bsd.port.mk:
PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aoutPorts' make processes should use this variable to decide what
to do. However, if the port's configure
script already automatically detects an ELF system, it is not
necessary to refer to PORTOBJFORMAT.Building shared librariesThe following are differences in handling shared
libraries for a.out and ELF.Shared library versionsAn ELF shared library should be called
libfoo.so.M
where M is the single version
number, and an a.out library should be called
libfoo.so.M.N where M is the major version and N is the the minor version number. Do not mix those; never install an ELF shared library called libfoo.so.N.M or an a.out shared library (or symlink) called libfoo.so.N.Linker command linesAssuming cc -shared is used rather than
ld directly, the only difference is that
you need to add
on the command line for ELF.You need to install a symlink from
libfoo.so to
libfoo.so.N to
make ELF linkers happy. Since it should be listed in
PLIST too, and it won't hurt in the a.out
case (some ports even require the link for dynamic loading), you
should just make this link regardless of the setting of
PORTOBJFORMAT.LIB_DEPENDSAll port Makefiles are edited to remove minor numbers from
LIB_DEPENDS, and also to have the regexp
support removed. (E.g., foo\\.1\\.\\(33|40\\)
becomes foo.2.) They will be matched using
grep -wF.PLISTPLIST should contain the short (ELF)
shlib names if the a.out minor number is zero, and the long
(a.out) names otherwise. bsd.port.mk will
automatically add .0 to the end of short shlib
lines if PORTOBJFORMAT equals
aout, and will delete the minor number from
long shlib names if PORTOBJFORMAT equals
elf.In cases where you really need to install shlibs with two
versions on an ELF system or those with one version on an a.out
system (for instance, ports that install compatibility libraries
for other operating systems), define the variable
NO_FILTER_SHLIBS. This will turn off the
editing of PLIST mentioned in the previous
paragraph.ldconfigThe ldconfig line in Makefiles should read:
${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....In PLIST it should read;
@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ...
@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -RThis is to ensure that the correct ldconfig
will be called depending on the format of the package, not the
default format of the system.MASTERDIRIf your port needs to build slightly different versions of
packages by having a variable (for instance, resolution, or paper
size) take different values, create one subdirectory per package
to make it easier forusers to see what to do, but try to share as
many files as possible between ports. Typically you only need a
very short Makefile in all but one of the
directories if you use variables cleverly. In the sole
Makefiles, you can use
MASTERDIR to specify the directory where the
rest of the files are. Also, use a variable as part of
PKGNAME
so the packages will have different names.This will be best demonstrated by an example. This is part of
japanese/xdvi300/Makefile;
PKGNAME= ja-xdvi${RESOLUTION}-17
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endifjapanese/xdvi300 also has all the regular
patches, package files, etc. If you type make
there, it will take the default value for the resolution (300) and
build the port normally.As for other resolutions, this is the
entirexdvi118/Makefile;
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile(xdvi240/Makefile and
xdvi400/Makefile are similar). The
MASTERDIR definition tells
bsd.port.mk that the refulat set of
subdirectories like PATCHDIR and
PKGDIR are to be found under
xdvi300. The
RESOLUTION=118 line will override the
RESOLUTION=300 line in
xdvi300/Makefile and the port will be built
with resolution set to 118.Shared library versionsFirst, please read our policy
on shared library versioning to understand
what to do with shared library versions in general. Do
not blindly assume software authors know what they are
doing; many of them do not. It is very important that
these details are carefully considered, as we have quite a
unique situation where we are trying to have dozens of
potentially incompatible software pairs co-exist.
Careless port imports have caused great trouble regarding
shared libraries in the past (ever wondered why the port
jpeg-6b has a shared library version of 9.0?).
If in doubt, send a message to the &a.ports;. Most of the
time, your job ends by determining the right shared
library version and making appropriate patches to
implement it.However, if there is a port which is a different version
of the same software already in the tree, the situation is
much more complex. In short, the FreeBSD implementation
does not allow the user to specify to the linker which
version of shared library to link against (the linker will
always pick the highest numbered version). This means, if
there is a libfoo.so.3.2 and libfoo.so.4.0 in
the system, there is no way to tell the linker to link a
particular application to libfoo.so.3.2. It is
essentially completely overshadowed in terms of
compilation-time linkage. In this case, the only solution
is to rename the base part of the shared library. For
instance, change libfoo.so.4.0 to
libfoo4.so.1.0 so both version 3.2 and 4.0 can be
linked from other ports.ManpagesThe MAN[1-9LN] variables will automatically
add any manpages to pkg/PLIST (this means you
must not list manpages in the
PLIST—see generating PLIST for more). It
also makes the install stage automatically compress or uncompress
manpages depending on the setting of
NOMANCOMPRESS in
/etc/make.conf.To specify whether the manpages are compressed upon
installation, use the MANCOMPRESSED variable.
This variable can take three values, yes,
no and maybe.
yes means manpages are already installed
compressed, no means they are not, and
maybe means the software already respects the
value of NOMANCOMPRESS so
bsd.port.mk does not have to do anything
special.MANCOMPRESSED is automatically set to
yes if USE_IMAKE is set and
NO_INSTALL_MANPAGES is not set, and to
no otherwise. You don't have to explicitly
define it unless the default is not suitable for your port.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages in
certain sections go in a non-standard place, such as some Perl
modules ports, you can set individual man paths using
MANsectPREFIX (where
sect is one of 1-9,
L or N).If your manpages go to language-specific subdirectories, set
the name of the languages to MANLANG. The
value of this variable defaults to "" (i.e.,
English only).Here is an example that puts it all together.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yesThis states that six files are installed by this port;
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gzPorts that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is
a free clone reported to be able to run many applications in
x11-toolkits/lesstif) to compile. Since
it is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically (for people who are compiling from the port) or
statically (for people who distribute packages).REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.MOTIFLIBThis variable will be set by
bsd.port.mk to be the appropriate reference
to the Motif library. Please patch the source to use this
wherever the Motif library is referenced in the
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its Makefile
or Imakefile, simply substitute
${MOTIFLIB} for
it.If the port uses XmClientLibs
in its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands to
-L/usr/X11R6/lib -lXm or
/usr/X11R6/lib/libXm.a, so there is no need
to add -L or -l in
front.X11 fontsIf your port installs fonts for the X Window system, put them
in
X11BASE/lib/X11/fonts/local.
This directory is new to XFree86 release 3.3.3. If it does not
exist, please create it, and print out a message urging the user
to update their XFree86 to 3.3.3 or newer, or at least add this
directory to the font path in
/etc/XF86Config.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info
to add and delete entries to the dir file. If
your port installs any info documents, please follow this
instructions so your port/package will correctly update the user's
PREFIX/info/dir
file. (Sorry for the length of this section, but is it imperative
to weave all the info files together. If done correctly, it will
produce a beautiful listing, so please bear
with me!First, this is what you (as a porter) need to know&prompt.user; install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
:
--entry=TEXT Insert TEXT as an Info directory entry.
:
--section=SEC Put this file's entries in section SEC of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995
+++ ./man/vip.texi Tue May 20 01:28:33 1997
@@ -2,6 +2,10 @@
@setfilename ../info/vip
@settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry
+* VIP: (vip). A VI-emulation for Emacs.
+@end direntry
@iftex
@finalout
:The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/04/15 06:32:12
@@ -15,9 +15,6 @@
man/man1/emacs.1.gz
man/man1/etags.1.gz
man/man1/ctags.1.gz
-@unexec cp %D/info/dir %D/info/dir.bak
-info/dir
-@unexec cp %D/info/dir.bak %D/info/dir
info/cl
info/cl-1
info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+ if [ ! -f ${PREFIX}/info/dir ]; then \
+ ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \
+ fi
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/05/20 10:25:12 1.17
@@ -16,7 +14,15 @@
man/man1/etags.1.gz
man/man1/ctags.1.gz
+@unexec install-info --delete %D/info/emacs %D/info/dir
:
+@unexec install-info --delete %D/info/ccmode %D/info/dir
info/cl
info/cl-1
@@ -87,6 +94,18 @@
info/viper-3
info/viper-4
+@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
+@exec install-info %D/info/emacs %D/info/dir
:
+@exec install-info %D/info/ccmode %D/info/dir
libexec/emacs/19.34/i386--freebsd/cvtmail
libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :). Check the dir file before and after each
step.The pkg/ subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.MESSAGEIf you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capability is often useful to display additional installation
steps to be taken after a pkg_add or to display
licensing information.The pkg/MESSAGE file does not need to
be added to pkg/PLIST. Also, it will not get
automatically printed if the user is using the port, not the
package, so you should probably display it from the
post-install target yourself.INSTALL
- If your port needs execute commands when the binary package is
- installed with pkg_add you can do with via the
+ If your port needs to execute commands when the binary package is
+ installed with pkg_add you can do this via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice by
pkg_add. The first time will as
INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be
tested to determine which mode the script is being run in. The
PKG_PREFIX environmental variable will be set to
the package installation directory. See pkg_add1 for additional
information.This script is not run automatically if you install the port
with make install. If you are depending on
- it being run, you will have to explicitly call it on your port's
+ it being run, you will have to explicitly call it from your port's
Makefile.REQIf your port needs to determine if it should install or not,
you can create a pkg/REQ
“requirements” script. It will be invoked
automatically at installation/deinstallation time to determine
whether or not installation/deinstallation should proceed.Changing PLIST based on make variablesSome ports, particularly the p5- ports, need to change their
PLIST depending on what options they are
configured with (or version of perl, in the case of p5- ports). To
make this easy, any instances in the PLIST of
%%OSREL%%, %%PERL_VER%%, and
%%PERL_VERSION%% will be substituted for
appropriately. The value of %%OSREL%% is the
numeric revision of the operating system (e.g.,
2.2.7). %%PERL_VERSION%% is
the full version number of perl (e.g., 5.00502)
and %%PERL_VER%% is the perl version number
minus the patchlevel (e.g., 5.005).If you need to make other substitutions, you can set the
PLIST_SUB variable with a list of
VAR=VALUE
pairs and instances of
%%VAR%%' will be
substituted with VALUE in the
PLIST.For instance, if you have a port that installs many files in
a version-specific subdirectory, you can put something
like
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
in the Makefile and use
%%OCTAVE_VERSION%% wherever the version shows
up in PLIST. That way, when you upgrade the
port, you will not have to change dozens (or in some cases,
hundreds) of lines in the PLIST.This substitution (as well as addition of any man pages) will be done
between the do-install and
post-install targets, by reading from
PLIST and writing to
TMPPLIST (default:
WRKDIR/.PLIST.mktmp). So
if your port builds PLIST on the fly, do so in
or before do-install. Also, if your port
needs to edit the resulting file, do so in
post-install to a file named
TMPPLIST.
+
+
+ Changing the names of files in the
+ pkg subdirectory
+
+ All the filenames in the pkg subdirectory
+ are defined using variables so you can change them in your
+ Makefile if need be. This is especially useful when you
+ are sharing the same pkg subdirectory among
+ several ports or have to write to one of the above files (see
+ writing to places other than
+ WRKDIR for why it is a bad idea to
+ write directly in to the pkg
+ subdirectory.
+
+ Here is a list of variable names and their default
+ values.
+
+
+
+
+
+ Variable
+ Default value
+
+
+
+
+
+ COMMENT
+ ${PKGDIR}/DESCR
+
+
+
+ DESCR
+ ${PKGDIR}/DESCR
+
+
+
+ PLIST
+ ${PKGDIR}/PLIST
+
+
+
+ PKGINSTALL
+ ${PKGDIR}/PKGINSTALL
+
+
+
+ PKGDEINSTALL
+ ${PKGDIR}/PKGDEINSTALL
+
+
+
+ PKGREQ
+ ${PKGDIR}/REQ
+
+
+
+ PKGMESSAGE
+ ${PKGDIR}/MESSAGE
+
+
+
+
+
+ Please change these variables rather than overriding
+ PKG_ARGS. If you change
+ PKG_ARGS, those files will not correctly be
+ installed in /var/db/pkg upon install from a
+ port.
+
-
+
Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
- can do with them vary a lot, depending on the exact wordings of
+ can do with them varies a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a “do not sell for profit” type of
license, set the variable NO_CDROM to a
string describing the reason why. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE to a string describing the
reason why. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a “no commercial use” license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (e.g., if your modified port
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category ports). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.You should check your own port
against this list, but you can also check ports in the PR
database that others have submitted. Submit any comments on
ports you check as described in Bug
Reports and General Commentary. Checking ports in
the PR database will both make it faster for us to commit them,
and prove that you know what you are doing.Strip BinariesDo strip binaries. If the original source already strips the
binaries, fine; otherwise you should add a
post-install rule to to it yourself. Here is an
example;
post-install:
strip ${PREFIX}/bin/xdlUse the file1 command on the installed executable to check
whether the binary is stripped or not. If it does not say
not stripped, it is stripped.INSTALL_* macrosDo use the macros provided in bsd.port.mk
to ensure correct modes and ownership of files in your own
*-install targets. They are:INSTALL_PROGRAM is a command to install
binary executables.INSTALL_SCRIPT is a command to install
executable scripts.INSTALL_DATA is a command to install
sharable data.INSTALL_MAN is a command to install
manpages and other documentation (it doesn't compress
anything).These are basically the install command
with all the appropriate flags. See below for an example on how
to use them.
+
+
+ WRKDIR
+
+ Do not write anything to files outside
+ WRKDIR. WRKDIR is the only
+ place that is guaranteed to be writable during the port build (see
+ compiling ports from CDROM for an
+ example of building ports from a read-only tree). If you need to
+ modigy some file in PKGDIR, do so by redefining a variable, not by
+ writing over it.
+
+
+
+ WRKDIRPREFIX
+
+ Make sure your port honors
+ WRKDIRPREFIX. Most ports don't have to worry
+ about this. In particular, if you are referring to a
+ WRKDIR of another port, note that the correct
+ location is
+ WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such.
+
+ Also, if you are defining WRKDIR yourself,
+ make sure you prepend
+ ${WKRDIRPREFIX}${.CURDIR} in the
+ front.
+ Differentiating operating systems and OS versionsYou may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as general
as possible so that we can back-port code to FreeBSD 1.x systems
and cross-port to other BSD systems such as 4.4BSD from CSRG,
BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file is
already included; if not, add the code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endifto the proper place in the .c file. We
- believe that every system that defines these to symbols has
+ believe that every system that defines these two symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to the
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile
for this method.Once you have sys/param.h
included, you may use:
#if (defined(BSD) && (BSD >= 199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:
#if (defined(BSD) && (BSD >= 199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is
199506 for the 4.4BSD-Lite2 code base. This is
stated for informational purposes only. It should not be used to
- distinguish between version of FreeBSD based only on 4.4-Lite vs.
+ distinguish between versions of FreeBSD based only on 4.4-Lite vs.
versions that have merged in changes from 4.4-Lite2. The
__FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
only affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endifRelease_FreeBSD_version2.0-RELEASE1194112.1-currents199501, 1995032.0.5-RELEASE1995042.2-current before 2.11995082.1.0-RELEASE1995112.2-current before 2.1.51995122.1.5-RELEASE1996072.2-current before 2.1.61996082.1.6-RELEASE1996122.1.7-RELEASE1996122.2-RELEASE2200002.2.1-RELEASE220000 (no change)2.2-STABLE after 2.2.1-RELEASE220000 (no change)2.2-STABLE after texinfo-3.92210012.2-STABLE after top2210022.2.2-RELEASE2220002.2-STABLE after 2.2.2-RELEASE2220012.2.5-RELEASE2250002.2-STABLE after 2.2.5-RELEASE2250012.2-STABLE after ldconfig -R merge2250022.2.6-RELEASE2260002.2.7-RELEASE2270002.2-STABLE after 2.2.7-RELEASE2270012.2-STABLE after semctl(2) change2270022.2.8-RELEASE2280002.2-STABLE after 2.2.8-RELEASE2280013.0-current before mount(2) change3000003.0-current after mount(2) change3000013.0-current after semctl(2) change3000023.0-current after ioctl arg changes3000033.0-current after ELF conversion3000043.0-RELEASE3000053.0-current after 3.0-RELEASE300006
+
+
+ 3.0-stable after 3/4 branch
+ 300007
+
+
+
+ 3.1-RELEASE
+ 310000
+
+
+
+ 3.1-stable after 3.1-RELEASE
+ 310001
+
+
+
+ 4.0-current after 3/4 branch
+ 400000
+ Note that 2.2-STABLE sometimes identifies itself as
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Writing something after
bsd.port.mkDo not write anything after the .include
<bsd.port.mk> line. it usually can be avoided by
including bsd.port.pre.mk somewhere in the
middle of your Makefile and
bsd.port.post.mk at the end.You need to include either the
pre.mk/post.mk pair or
bsd.port.mk only; don't mix these
two.bsd.port.pre.mk only defines a few
variables, which can be used in tests in the
Makefile,
bsd.port.post.mk defines the rest.Here are some important variables defined in
bsd.port.pre.mk (this is not the complete
list, please read bsd.port.mk for the
complete list).VariableDescriptionARCHThe architecture as returned by uname
-m (e.g., i386)OPSYSThe operating system type, as returned by
uname -s (e.g.,
FreeBSD)OSRELThe release version of the operating system (e.g.,
2.1.5 or
2.2.7)OSVERSIONThe numeric version of the operating system, same as
__FreeBSD_version.PORTOBJFORMATThe object format of the system
(aout or elfLOCALBASEThe base of the “local” tree (e.g.,
/usr/local/)X11BASEThe base of the “X11” tree (e.g.,
/usr/X11R6)PREFIXWhere the port installs itself (see more on
PREFIX).If you have to define the variables
USE_IMAKE, USE_X_PREFIX,
or MASTERDIR, do so before including
bsd.port.pre.mk.Here are some examples of things you can write after
bsd.port.pre.mk;
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endifInstall additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
PREFIX/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means PKGNAME minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole PKGNAME.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)Also you can use the pkg/MESSAGE file to
display messages upon installation. See the using
pkg/MESSAGE section for
details.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
Makefile), set DIST_SUBDIR to the name of the
port (PKGNAME without the
version part should work fine). This will change DISTDIR from the default
/usr/ports/distfiles to
/usr/ports/distfiles/DIST_SUBDIR,
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting DISTDIR explicitly in your
Makefile will not accomplish this, so please use DIST_SUBDIR.)This does not affect the MASTER_SITES you define in your
Makefile.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
NO_PACKAGE is
set.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. If you had to edit
configure.in and run
autoconf to regenerate
configure, do not take the diffs of
configure (it often grows to a few thousand
lines!); define USE_AUTOCONF=yes and take the
diffsof configure.in.Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resulting diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to PREFIX. (The value of this
variable will be set to LOCALBASE (default
/usr/local), unless USE_X_PREFIX or USE_IMAKE is set, in which case it
will be X11BASE (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read PREFIX, as this
variable is automatically passed down to every stage of the
build and install processes.Do not set USE_X_PREFIX unless your port
truly require it (i.e., it links against X libs or it needs to
reference files in X11BASE).The variable PREFIX
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles.Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\"
or
-DPAGER=\"${LOCALBASE}/bin/less\"
if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of PREFIX. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
- details, the rule governing /usr pretty
- much applies to /usr/local too. The
+ details, the rules governing /usr pretty
+ much apply to /usr/local too. The
exception are ports dealing with USENET “news”. They may use
PREFIX/news as a destination for
their files.Cleaning up empty directoriesDo make your ports clean up after themselves when they are
deinstalled. This is usually accomplished by adding
@dirrm lines for all directories that are
specifically created by the port. You need to delete
subdirectories before you can delete parent directories.
:
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
:
@dirrm lib/X11/oneko/pixmals
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/onekoHowever, sometimes @dirrm will give you
errors because other ports also share the same subdirectory. You
can call rmdir from @unexec
to remove only empty directories without warning.
@unexec rmdir %D/share/doc/gimp 2>/dev/null || trueThis will neither print any error messages nor cause
pkg_delete to exit abnormally even if
PREFIX/share/doc/gimp is
not empty due to other ports installing some files in there.UIDsIf your port requires a certain user to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at net/cvsup-mirror
for an example.If your port must use the same user/group ID number when it is
installed a binarypackage as when it was compiled, then you mus
choose a free UID from 50 to 99 and register it below. Look at
japanese/Wnn for an example.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/shPlease include a notice when you submit a port (or an
upgrade) that reserves a new UID or GID in this range. This allows
us to keep the list of reserved IDs up to date.Do things rationallyThe Makefile should do things simply and
reasonably. If you can make it a couple of lines shorter or more
readable, then do so. Examples include using a make
.if construct instead of a shell
if construct, not redefining
do-extract if you can redefine
EXTRACT* instead, and using
GNU_CONFIGURE instead of
CONFIGURE_ARGS +=
--prefix=${PREFIX}.Respect CFLAGSThe port should respect the CFLAGS
variable. If it doesn't, please add NO_PACKAGE=ignores
cflags to the Makefile.Configuration filesIf your port requires some configuration files in
PREFIX/etc, do
not just install them and list them in
pkg/PLIST. That will cause
pkg_delete to delete files carefully edited by
the user and a new installation to wipe them out.Instead, install sample files with a suffix
(filename.sample
will work well) and print out a message pointing out that the
user has to copy and edit the file before the software can be made
to work.PortlintDo check your work with portlint
before you submit or commit it.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code. This
will only make your job that much easier for the next
release.MiscellaneaThe files pkg/DESCR,
pkg/COMMENT, and
pkg/PLIST should each be double-checked. If
you are reviewing a port and feel they can be worded better, do
so.Don't copy more copies of the GNU General Public License into
our system, please.Please be careful to note any legal issues! Don't let us
illegally distribute software!If you are stuck…Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample MakefileHere is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). This format is
designed so that the most important information is easy to
locate. We recommend that you use portlint to check the Makefile.
[the header...just to make it easier for us to identify the ports.]
# New ports collection makefile for: xdvi
[the version required header should updated when upgrading a port.]
# Version required: pl18 [things like "1.5alpha" are fine here too]
[this is the date when the first version of this Makefile was created.
Never change this when doing an update of the port.]
# Date created: 26 May 1995
[this is the person who did the original port to FreeBSD, in particular, the
person who wrote the first version of this Makefile. Remember, this should
not be changed when upgrading the port later.]
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
#
# $Id$
[ ^^^^ This will be automatically replaced with RCS ID string by CVS
when it is committed to our repository.]
#
[section to describe the port itself and the master site - DISTNAME
is always first, followed by PKGNAME (if necessary), CATEGORIES,
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be specified too.]
DISTNAME= xdvi
PKGNAME= xdvi-pl18
CATEGORIES= print
[do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros]
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz" form]
EXTRACT_SUFX= .tar.Z
[section for distributed patches -- can be empty]
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[maintainer; *mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug reports - this
person should be the porter or someone who can forward questions to the
original porter reasonably promptly. If you really do not want to have
your address here, set it to "ports@FreeBSD.ORG".]
MAINTAINER= asami@FreeBSD.ORG
[dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm
[this section is for other standard bsd.port.mk variables that do not
belong to any of the above]
[If it asks questions during configure, build, install...]
IS_INTERACTIVE= yes
[If it extracts to a directory other than ${DISTNAME}...]
WRKSRC= ${WRKDIR}/xdvi-new
[If the distributed patches were not made relative to ${WRKSRC}, you
may need to tweak this]
PATCH_DIST_STRIP= -p1
[If it requires a "configure" script generated by GNU autoconf to be run]
GNU_CONFIGURE= yes
[If it requires GNU make, not /usr/bin/make, to build...]
USE_GMAKE= yes
[If it is an X application and requires "xmkmf -a" to be run...]
USE_IMAKE= yes
[et cetera.]
[non-standard variables to be used in the rules below]
MY_FAVORITE_RESPONSE= "yeah, right"
[then the special rules, in the order they are called]
pre-fetch:
i go fetch something, yeah
post-patch:
i need to do something after patch, great
pre-install:
and then some more stuff before installing, wow
[and then the epilogue]
.include <bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like language-name-compiled.specifics-version.numbers.If your DISTNAME
doesn't look like that, set PKGNAME to something in that
format.FreeBSD strives to support the native language of its
users. The language- part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
ja for Japanese, ru for Russian, vi for Vietnamese,
zh for Chinese, ko for Korean and de for German.The name part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a port of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the capital letters are
important to the name (for example, with one-letter names
like R or V) you may use capital letters at your discretion.
There is a tradition of naming Perl 5 modules by prepending
p5- and converting the double-colon separator to a hyphen;
for example, the Data::Dumper module becomes
p5-Data-Dumper. If the software in question has numbers,
hyphens, or underscores in its name, you may include them as
well (like kinput2).If the port can be built with different hardcoded
defaults (usually part of the directory name in a
family of ports), the
-compiled.specifics part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string pl (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a DISTNAME into a suitable PKGNAME:Distribution NamePackage NameReasonmule-2.2.2.mule-2.2.2No changes requiredXFree86-3.1.2XFree86-3.1.2No changes requiredEmiClock-1.0.2emiclock-1.0.2No uppercase names for single programsgmod1.4gmod-1.4Need a hyphen before version numbersxmris.4.0.2xmris-4.0.2Need a hyphen before version numbersrdist-1.3alphardist-1.3aNo strings like alpha
allowedes-0.9-beta1es-0.9b1No strings like beta
allowedv3.3beta021.srctiff-3.3What the heck was that anyway?tvtwmtvtwm-pl11Version string always requiredpiewmpiewm-1.0Version string always requiredxvgr-2.10pl1xvgr-2.10.1pl allowed only when no
major/minor version numbersgawk-2.15.6ja-gawk-2.15.6Japanese language versionpsutils-1.13psutils-letter-1.13Papersize hardcoded at package build timepkfontspkfonts300-1.0Package for 300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to 1.0 (like the piewm example above). Otherwise, ask the
original author or use the date string (yy.mm.dd) as the
version.CategoriesAs you already know, ports are classified in several
categories. But for this to wor, it is important that porters and
users understand what each category and how we deicde what to put in
each category.Current list of categoriesFirst, this is the current list of port categories. Those
marked with an asterisk (*) are
virtual categories—those that do not
have a corresponding subdirectory in the ports tree.For non-virtual categories, you will find a one-line
description in the pkg/COMMENT file in that
subdirectory (e.g.,
archivers/pkg/COMMENT).CategoryDescription
+
+ afterstep*
+ Ports to support AfterStep window manager
+
+
archiversArchiving tools.astroAstronomical ports.audioSound support.benchmarksBenchmarking utilities.biologyBiology-related software.cadComputer aided design tools.chineseChinese language support.commsCommunication software. Mostly software to talk to
your serial port.convertersCharacter code converters.databasesDatabases.deskutilsThings that used to be on the desktop before
computers were invented.develDevelopment utilities. Do not put libraries here just
because they are libraries—unless they truly don't
belong to anywhere else, they shouldn't be in this
category.editorsGeneral editors. Specialized editors go in the
section for those tools (e.g., a mathematical-formula
editor will go in math).elispEmacs-lisp ports.emulatorsEmulators for other operating systems. Terminal
emulators do not belong
here—X-based ones should go to
x11 and text-based ones to either
comms or misc,
depending on the exact functionality.gamesGames.germanGerman language support.graphicsGraphics utilities.japaneseJapanese language support.kde*Ports that form the K Desktop Environment
(kde).koreanKorean language support.langProgramming languages.mailMail software.mathNumerical computation software and other utilities
for mathematics.mboneMBone applications.miscMiscellaneous utilities—basically things that
doesn't belong to anywhere else. This is the only category
that should not appear with any other non-virtual
category. If you have misc with
something else in your CATEGORIES line,
that means you can safely delete misc
and just put the port in that other subdirectory!netMiscellaneous networking software.newsUSENET news software.offix*Ports from the OffiX suite.
- perl5*
- Ports that require perl version 5 to run.
+ palm
+ Software support for the 3Com Palm(tm) series.
-
+
- pilot*
- Software to use with the 3Com PalmPilot.
+ perl5*
+ Ports that require perl version 5 to run.
- plan9
+ plan9*Various programs from Plan9.printPrinting software. Desktop publishing tools
(previewers, etc.) belong here too.python*Software written in python.russianRussian language support.securitySecurity utilities.shellsCommand line shells.sysutilsSystem utilities.tcl75*Ports that use tcl version 7.5 to run.tcl76*Ports that use tcl version 7.6 to run.tcl80*Ports that use tcl version 8.0 to run.tcl81*Ports that use tcl version 8.1 to run.textprocText processing utilities. It does not include
desktop publishing tools, which go to print/.tk41*Ports that use tk version 4.1 to run.tk42*Ports that use tk version 4.2 to run.tk80*Ports that use tk version 8.0 to run.tk81*Ports that use tk version 8.1 to run.vietnameseVietnamese language support.
+
+ windowmaker*
+ Ports to support the WindowMaker window
+ manager
+
+
wwwSoftware related to the World Wide Web. HTML language
support belong here too.x11The X window system and friends. This category is
only for software that directly support the window system.
Do not put regular X applications here. If your port is
an X application, define USE_XLIB
(implied by USE_IMAKE) and put it in
appropriate categories. Also, many of them go into other
x11-* categories (see below).x11-clocksX11 clocks.x11-fmX11 file managers.x11-fontsX11 fonts and font utilities.x11-toolkitsX11 toolkits.x11-wmX11 window managers.Choosing the right categoryAs many of the categories overlap, you often have to choose
which of the categories should be the primary category of your
port. There are several rules that govern this usse. Here is the
list of priorities, in decreasing order of precedence.Language specific categories alwasys come first. For
example, if your port installs Japanese X11 fonts, then your
CATEGORIES line would read
japanese x11.Specific categories win over less-specific ones. For
instance, an HTML editor should be listed as www
editors, not the other way around. Also, you don't
need to list net when the port belongs to
either of mail, mbone,
news, security, or
www.x11 is used as a secondary category
only when the primary category is a natural language. In
particular, you should not put x11 in the
category line for X applications.If your port truly does not belong anywhere else, put it
in misc.If you are not sure about the category, please put a comment
to that effect in your send-pr submission so we
can discuss it before import it. (If you are a committer, send a
note &a.ports; so we can discuss it first—too often new
ports are imported to a wrong category only to be moved right
away.)Changes to this document and the ports systemIf you maintain a lot of ports, you should consider following
the &a.ports;. Important changes to
the way ports work will be announced there. You can always
find more detailed information on the latest changes by
looking at
the bsd.port.mk CVS log.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)
diff --git a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
index 00fcb1dc43..ccc28daebc 100644
--- a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
@@ -1,1710 +1,1711 @@
SecurityDES, MD5, and CryptContributed by &a.wollman;24 September
1995.In order to protect the security of passwords on UN*X systems
from being easily exposed, passwords have traditionally been
scrambled in some way. Starting with Bell Labs' Seventh Edition
Unix, passwords were encrypted using what the security people call a
“one-way hash function”. That is to say, the password is
transformed in such a way that the original password cannot be
regained except by brute-force searching the space of possible
passwords. Unfortunately, the only secure method that was available
to the AT&T researchers at the time was based on DES, the Data
Encryption Standard. This causes only minimal difficulty for
commercial vendors, but is a serious problem for an operating system
like FreeBSD where all the source code is freely available, because
national governments in many places like to place restrictions on
cross-border transport of DES and other encryption software.So, the FreeBSD team was faced with a dilemma: how could we
provide compatibility with all those UNIX systems out there while
still not running afoul of the law? We decided to take a dual-track
approach: we would make distributions which contained only a
non-regulated password scrambler, and then provide as a separate
add-on library the DES-based password hash. The password-scrambling
function was moved out of the C library to a separate library,
called libcrypt because the name of
the C function to implement it is crypt. In FreeBSD 1.x and some pre-release
2.0 snapshots, the non-regulated scrambler uses an insecure function
written by Nate Williams; in subsequent releases this was replaced
by a mechanism using the RSA Data Security, Inc., MD5 one-way hash
function. Because neither of these functions involve encryption,
they are believed to be exportable from the US and importable into
many other countries.Meanwhile, work was also underway on the DES-based password hash
function. First, a version of the crypt function which was written outside the
US was imported, thus synchronizing the US and non-US code. Then,
the library was modified and split into two; the DES libcrypt contains only the code involved in
performing the one-way password hash, and a separate libcipher was created with the entry points
to actually perform encryption. The code was partitioned in this
way to make it easier to get an export license for the compiled
library.Recognizing your crypt
mechanismIt is fairly easy to recognize whether a particular password
string was created using the DES- or MD5-based hash function. MD5
password strings always begin with the characters $1$. DES password strings do not
have any particular identifying characteristics, but they are
shorter than MD5 passwords, and are coded in a 64-character
alphabet which does not include the $ character, so a relatively short
string which doesn't begin with a dollar sign is very likely a DES
password.Determining which library is being used on your system is
fairly easy for most programs, except for those like init which are statically linked. (For
those programs, the only way is to try them on a known password
and see if it works.) Programs which use crypt are linked against libcrypt, which for each type of library is
a symbolic link to the appropriate implementation. For example,
on a system using the DES versions:&prompt.user; cd /usr/lib
&prompt.user; ls -l /usr/lib/libcrypt*
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.aOn a system using the MD5-based libraries, the same links will
be present, but the target will be libscrypt
rather than libdescrypt.S/KeyContributed by &a.wollman;25 September
1995.S/Key is a one-time password scheme based on a one-way hash
function (in our version, this is MD4 for compatibility; other
versions have used MD5 and DES-MAC). S/Key has been a standard part
of all FreeBSD distributions since version 1.1.5, and is also
implemented on a large and growing number of other systems. S/Key
is a registered trademark of Bell Communications Research,
Inc.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual UNIX-style
or Kerberos password; we will call this a “UNIX password”. The
second sort is the one-time password which is generated by the S/Key
key program and accepted by the
keyinit program and the login
prompt; we will call this a “one-time password”. The final sort
of password is the secret password which you give to the key program (and sometimes the keyinit program) which it uses to generate
one-time passwords; we will call it a “secret password” or just
unqualified “password”.The secret password does not necessarily have anything to do
with your UNIX password (while they can be the same, this is not
recommended). While UNIX passwords are limited to eight characters
in length, your S/Key secret password can be as long as you like; I
use seven-word phrases. In general, the S/Key system operates
completely independently of the UNIX password system.There are in addition two other sorts of data involved in the
S/Key system; one is called the “seed” or (confusingly) “key”,
and consists of two letters and five digits, and the other is the
“iteration count” and is a number between 100 and 1. S/Key
constructs a one-time password from these components by
concatenating the seed and the secret password, then applying a
one-way hash (the RSA Data Security, Inc., MD4 secure hash function)
iteration-count times, and turning the result into six short English
words. The login and su programs keep track of the last one-time
password used, and the user is authenticated if the hash of the
user-provided password is equal to the previous password. Because a
one-way hash function is used, it is not possible to generate future
one-time passwords having overheard one which was successfully used;
the iteration count is decremented after each successful login to
keep the user and login program in sync. (When you get the
iteration count down to 1, it is time to reinitialize S/Key.)There are four programs involved in the S/Key system which we
will discuss below. The key program
accepts an iteration count, a seed, and a secret password, and
generates a one-time password. The keyinit program is used to initialized S/Key,
and to change passwords, iteration counts, or seeds; it takes either
a secret password, or an iteration count, seed, and one-time
password. The keyinfo program
examines the /etc/skeykeys file and prints out
the invoking user's current iteration count and seed. Finally, the
login and su programs contain the necessary logic to
accept S/Key one-time passwords for authentication. The login program is also capable of disallowing
the use of UNIX passwords on connections coming from specified
addresses.There are four different sorts of operations we will cover. The
first is using the keyinit program
over a secure connection to set up S/Key for the first time, or to
change your password or seed. The second operation is using the
keyinit program over an insecure
connection, in conjunction with the key program over a secure connection, to do
the same. The third is using the key program to log in over an insecure
connection. The fourth is using the key program to generate a number of keys
which can be written down or printed out to carry with you when
going to some location without secure connections to anywhere (like
at a conference).Secure connection initializationTo initialize S/Key, change your password, or change your seed
while logged in over a secure connection (e.g., on the console of
a machine), use the keyinit
command without any parameters while logged in as yourself:&prompt.user; keyinit
Updating wollman: ) these will not appear if you
Old key: ha73895 ) have not used S/Key before
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password: ) I typed my pass phrase here
Again secret password: ) I typed it again ID
wollman s/key is 99 ha73896 ) discussed below SAG
HAS FONT GOUT FATE BOOM )There is a lot of information here. At theEnter secret
password: prompt, you should enter some password or phrase (I use
phrases of minimum seven words) which will be needed to generate
login keys. The line starting `ID' gives the parameters of your
particular S/Key instance: your login name, the iteration count,
and seed. When logging in with S/Key, the system will remember
these parameters and present them back to you so you do not have
to remember them. The last line gives the particular one-time
password which corresponds to those parameters and your secret
password; if you were to re-login immediately, this one-time
password is the one you would use.Insecure connection initializationTo initialize S/Key or change your password or seed over an
insecure connection, you will need to already have a secure
connection to some place where you can run the key program; this might be in the form of a
desk accessory on a Macintosh, or a shell prompt on a machine you
trust (we will show the latter). You will also need to make up an
iteration count (100 is probably a good value), and you may make
up your own seed or use a randomly-generated one. Over on the
insecure connection (to the machine you are initializing), use the
keyinit -s command:&prompt.user; keyinit -s
Updating wollman: Old key: kh94741
Reminder you need the 6 English words from the skey command.
Enter sequence count from 1 to 9999:100 ) I typed this
Enter new key [default kh94742]:
s/key 100 kh94742To accept the default seed (which the keyinit program
confusingly calls a key), press return. Then move over to your
secure connection or S/Key desk accessory, and give it the same
parameters:&prompt.user; key 100 kh94742
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
HULL NAY YANG TREE TOUT VETONow switch back over to the insecure connection, and copy the
one-time password generated by key
over to the keyinit
program:s/key access password:HULL NAY YANG TREE TOUT VETO
ID wollman s/key is 100 kh94742
HULL NAY YANG TREE TOUT VETOThe rest of the description from the previous section applies
here as well.Diversion: a login promptBefore explaining how to generate one-time passwords, we
should go over an S/Key login prompt:&prompt.user; telnet himalia
Trying 18.26.0.186...
Connected to himalia.lcs.mit.edu.
Escape character is '^]'.
s/key 92 hi52030
Password:Note that, before prompting for a password, the login program
prints out the iteration number and seed which you will need in
order to generate the appropriate key. You will also find a
useful feature (not shown here): if you press return at the
password prompt, the login program will turn echo on, so you can
see what you are typing. This can be extremely useful if you are
attempting to type in an S/Key by hand, such as from a
printout.If this machine were configured to disallow UNIX passwords
over a connection from my machine, the prompt would have also
included the annotation (s/key
required), indicating that only S/Key one-time
passwords will be accepted.Generating a single one-time passwordNow, to generate the one-time password needed to answer this
login prompt, we use a trusted machine and the key program. (There are versions of the
key program from DOS and Windows
machines, and there is an S/Key desk accessory for Macintosh
computers as well.) The command-line key program takes as its parameters the
iteration count and seed; you can cut-and-paste right from the
login prompt starting at key to
the end of the line. Thus:&prompt.user; key 92 hi52030 ) pasted from previous section
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
ADEN BED WOLF HAW HOT STUNAnd in the other window:s/key 92 hi52030 ) from previous section
Password:
(turning echo on)
Password:ADEN BED WOLF HAW HOT STUN
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
[etc.]This is the easiest mechanism if you have
a trusted machine. There is a Java S/Key key applet, The Java OTP
Calculator, that you can download and run locally on any
Java supporting brower.Generating multiple one-time passwordsSometimes we have to go places where no trusted machines or
connections are available. In this case, it is possible to use
the key command to generate a
number of one-time passwords in the same command; these can then
be printed out. For example:&prompt.user; key -n 25 57 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
33: WALT THY MALI DARN NIT HEAD
34: ASK RICE BEAU GINA DOUR STAG
…
56: AMOS BOWL LUG FAT CAIN INCH
57: GROW HAYS TUN DISH CAR BALMThe requests twenty-five keys in
sequence; the indicates the
ending iteration number; and the rest is as
before. Note that these are printed out in
reverse order of eventual use. If you are
really paranoid, you might want to write the results down by hand;
otherwise you can cut-and-paste into lpr. Note that each line shows both the
iteration count and the one-time password; you may still find it
handy to scratch off passwords as you use them.Restricting use of UNIX passwordsThe configuration file /etc/skey.access
can be used to configure restrictions on the use of UNIX passwords
based on the host name, user name, terminal port, or IP address of
a login session. The complete format of the file is documented in
the skey.access5 manual page; there are
also some security cautions there which should be read before
depending on this file for security.If there is no /etc/skey.access file
(which is the default state as FreeBSD is shipped), then all users
will be allowed to use UNIX passwords. If the file exists,
however, then all users will be required to use S/Key unless
explicitly permitted to do otherwise by configuration statements
in the skey.access file. In all cases, UNIX
passwords are permitted on the console.Here is a sample configuration file which illustrates the
three most common sorts of configuration statements:
permit internet 18.26.0.0 255.255.0.0
permit user jrl
permit port ttyd0The first line (permit
internet) allows users whose IP source address
(which is vulnerable to spoofing) matches the specified value and
mask, to use UNIX passwords. This should not be considered a
security mechanism, but rather, a means to remind authorized users
that they are using an insecure network and need to use S/Key for
authentication.The second line (permit user)
allows the specified user to use UNIX passwords at any time.
Generally speaking, this should only be used for people who are
either unable to use the key
program, like those with dumb terminals, or those who are
uneducable.The third line (permit port)
allows all users logging in on the specified terminal line to use
UNIX passwords; this would be used for dial-ups.KerberosContributed by &a.markm; (based on contribution by
&a.md;).Kerberos is a network add-on system/protocol that allows users
to authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and
more controllable.The following instructions can be used as a guide on how to set
up Kerberos as distributed for FreeBSD. However, you should refer to
the relevant manual pages for a complete description.In FreeBSD, the Kerberos is not that from the original
4.4BSD-Lite, distribution, but eBones, which had been previously
ported to FreeBSD 1.1.5.1, and was sourced from outside the
USA/Canada, and is thus available to system owners outside those
countries.For those needing to get a legal foreign distribution of this
software, please do not get it from a USA or
Canada site. You will get that site in big
trouble! A legal copy of this is available from
ftp.internat.freebsd.org, which is in
South Africa and an official FreeBSD mirror site.Creating the initial databaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should
change to the directory /etc/kerberosIV and
check that only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as
principal.* or master_key)
exist, then use the kdb_destroy command to
destroy the old Kerberos database, of if Kerberos is not running,
simply delete the extra files.You should now edit the krb.conf and
krb.realms files to define your Kerberos
realm. In this case the realm will be
GRONDAR.ZA and the server is
grunt.grondar.za. We edit or create the
krb.conf file:&prompt.root; cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They
are here as an example of how a machine may be made aware of
multiple realms. You may wish to not include them for
simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line
is a realm, and the second is a host in that realm that is acting
as a “key distribution centre”. The words admin server
following a hosts name means that host also provides an
administrative database server. For further explanation of these
terms, please consult the Kerberos man pages.Now we have to add grunt.grondar.za to
the GRONDAR.ZA realm and also add an entry to
put all hosts in the .grondar.za domain in
the GRONDAR.ZA realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here
as an example of how a machine may be made aware of multiple
realms. You may wish to remove them to simplify things.The first line puts the specific
system into the named realm. The rest of the lines show how to
default systems of a particular subdomain to a named realm.Now we are ready to create the database. This only needs to
run on the Kerberos server (or Key Distribution Centre). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:GRONDAR.ZA
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local
machine can pick it up. Use the kstash command to do this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making it all runTwo principals need to be added to the database for each system that will be secured with
Kerberos. Their names are kpasswd
and rcmd These two principals are
made for each system, with the instance being the name of the
individual system.These daemons, kpasswd and
rcmd allow other systems to change
Kerberos passwords and run commands like rcp, rlogin
and rsh.Now let's add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the server fileWe now have to extract all the instances which define the
services on each machine. For this we use the
ext_srvtab command. This will create a file which
must be copied or moved by secure
means to each Kerberos client's /etc/kerberosIV
directory. This file must be present on each server and client,
and is crucial to the operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must
be renamed to srvtab so that all the
server can pick it up. Use the mv
command to move it into place on the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not
deemed safe, then copy the client-new-srvtab to removable media
and transport it by secure physical means. Be sure to rename it to
srvtab in the client's
/etc/kerberosIV directory, and make sure it
is mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the databaseWe now have to add some user entries into the database. First
let's create an entry for the user jane. Use
the kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting it all outFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then
this will happen automatically when you reboot. This is only
necessary on the Kerberos server. Kerberos clients will
automagically get what they need from the
/etc/kerberosIV directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit
command to get a ticket for the id jane that we created above:&prompt.user; kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZANow try changing the password using passwd to check if the kpasswd daemon can
get authorization to the Kerberos database:&prompt.user; passwd
realm GRONDAR.ZA
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su privilegesKerberos allows us to give each
user who needs root privileges their own separatesupassword. We could now add an id which is
authorized to su to root. This is controlled by having an
instance of root associated with a
principal. Using kdb_edit we can create the
entry jane.root in the Kerberos
database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's
.klogin file:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZANow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZAUsing other commandsIn an earlier example, we created a principal called
jane with an instance root. This was based on a user with the same
name as the principal, and this is a Kerberos default; that a
<principal>.<instance> of the
form <username>.root will allow that
<username> to su to root if the necessary entries are in
the .klogin file in root's home directory:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZALikewise, if a user has in their own home directory lines of
the form:&prompt.user; cat ~/.klogin
jane@GRONDAR.ZA
jack@GRONDAR.ZAThis allows anyone in the GRONDAR.ZA
realm who has authenticated themselves to
jane or jack (via
kinit, see above) access to
rlogin to
jane's account or files on this system
(grunt) via rlogin, rsh or
rcp.For example, Jane now logs into another system, using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.grondar.za)
Password:
%prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine (Jane
having set up the .klogin file as above, and
the person in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.grondar.za)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995FirewallsContributed by &a.gpalmer; and
&a.alex;.Firewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on
private networks to provide enhanced security. This section will
hopefully explain what firewalls are, how to use them, and how to
use the facilities provided in the FreeBSD kernel to implement
them.People often think that having a firewall between your
companies internal network and the “Big Bad Internet”
will solve all your security problems.It may help, but a poorly setup firewall system is more of a
security risk than not having one at all. A firewall can only add
another layer of security to your systems, but they will not be
able to stop a really determined cracker from penetrating your
internal network. If you let internal security lapse because you
believe your firewall to be impenetrable, you have just made the
crackers job that bit easier.What is a firewall?There are currently two distinct types of firewalls in common
use on the Internet today. The first type is more properly called
a packet filtering router, where the
kernel on a multi-homed machine chooses whether to forward or
block packets based on a set of rules. The second type, known as
proxy servers, rely on daemons to
provide authentication and to forward packets, possibly on a
multi-homed machine which has kernel packet forwarding
disabled.Sometimes sites combine the two types of firewalls, so that
only a certain machine (known as a bastion
host) is allowed to send packets through a packet
filtering router onto an internal network. Proxy services are run
on the bastion host, which are generally more secure than normal
authentication mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this section
will concentrate on. Proxy servers can be built on FreeBSD from
third party software, but there is such a variety of proxy servers
available that it would be impossible to cover them in this
document.Packet filtering routersA router is a machine which forwards packets between two or
more networks. A packet filtering router has an extra piece of
code in its kernel, which compares each packet to a list of
rules before deciding if it should be forwarded or not. Most
modern IP routing software has packet filtering code in it,
which defaults to forwarding all packets. To enable the filters,
you need to define a set of rules for the filtering code, so
that it can decide if the packet should be allowed to pass or
not.To decide if a packet should be passed on or not, the code
looks through its set of rules for a rule which matches the
contents of this packets headers. Once a match is found, the
rule action is obeyed. The rule action could be to drop the
packet, to forward the packet, or even to send an ICMP message
back to the originator. Only the first match counts, as the
rules are searched in order. Hence, the list of rules can be
referred to as a “rule chain”.The packet matching criteria varies depending on the
software used, but typically you can specify rules which depend
on the source IP address of the packet, the destination IP
address, the source port number, the destination port number
(for protocols which support ports), or even the packet type
(UDP, TCP, ICMP, etc).Proxy serversProxy servers are machines which have had the normal system
daemons (telnetd, ftpd, etc) replaced with special servers.
These servers are called proxy
servers as they normally only allow onward
connections to be made. This enables you to run (for example) a
proxy telnet server on your firewall host, and people can telnet
in to your firewall from the outside, go through some
authentication mechanism, and then gain access to the internal
network (alternatively, proxy servers can be used for signals
coming from the internal network and heading out).Proxy servers are normally more secure than normal servers,
and often have a wider variety of authentication mechanisms
available, including “one-shot” password systems so that even
if someone manages to discover what password you used, they will
not be able to use it to gain access to your systems as the
password instantly expires. As they do not actually give users
access to the host machine, it becomes a lot more difficult for
someone to install backdoors around your security system.Proxy servers often have ways of restricting access further,
so that only certain hosts can gain access to the servers, and
often they can be set up so that you can limit which users can
talk to which destination machine. Again, what facilities are
available depends largely on what proxy software you
choose.What does IPFW allow me to do?IPFW, the software supplied with FreeBSD,
is a packet filtering and accounting system which resides in the
kernel, and has a user-land control utility,
ipfw8. Together, they allow you to define and
query the rules currently used by the kernel in its routing
decisions.There are two related parts to IPFW. The
firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of
your router, based on similar rules to the firewall section. This
allows you to see (for example) how much traffic your router is
getting from a certain machine, or how much WWW (World Wide Web)
traffic it is forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDAs the main part of the IPFW system lives
in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want,
and recompile your kernel. See
reconfiguring the kernel for
more details on how to recompile your kernel.There are currently three kernel configuration options
relevant to IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
syslogd8. Without this option, even
if you specify that packets should be logged in the filter
rules, nothing will happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
syslogd8 on a per entry basis. You
may wish to use this option in hostile environments in
which you want to log firewall activity, but do not want
to be open to a denial of service attack via syslog
flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To
resume logging, you will need to reset the associated
counter using the ipfw8
utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWThe configuration of the IPFW software is
done through the ipfw8 utility. The syntax
for this command looks quite complicated, but it is relatively
simple once you understand its structure.There are currently four different command categories used by
the utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how
packets are accepted, rejected, and logged. Listing is used to
examine the contents of your rule set (otherwise known as the
chain) and packet counters (accounting). Flushing is used to
remove all entries from the chain. Clearing is used to zero out
one or more accounting entries.Altering the IPFW rulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in
output.The command given can be shortened to
the shortest unique form. The valid
commands are:addAdd an entry to the firewall/accounting rule
listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used separate
firewall and accounting entries. The present version provides
packet accounting with each firewall entry.If an index value is supplied,
it used to place the entry at a specific point in the chain.
Otherwise, the entry is placed at the end of the chain at an
index 100 greater than the last chain entry (this does not
include the default policy, rule 65535, deny).The log option causes matching
rules to be output to the system console if the kernel was
compiled with IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port
unreachable (as appropriate) packet to the
source.allowPass the packet on as normal. (aliases:
pass and accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the
packet based on this rule. The search continues with
the next chain entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/markportvia interfaceYou can only specify port in
conjunction with protocols which support
ports (UDP and TCP).The is optional and may
specify the IP address or domain name of a local IP interface,
or an interface name (e.g. ed0) to
match only packets coming through this interface. Interface unit
numbers can be specified with an optional wildcard. For example,
ppp* would match all kernel PPP
interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP
address. is a decimal
number representing how many bits in the address mask should be
set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any
address in a class C subnet (in this case, 192.216.222) to be
matched. is an IP
address which will be logically AND'ed with the address given.
The keyword any may be used to
specify “any IP address”.The port numbers to be blocked are specified as:
port,port,port…to specify either a single port or a list of
ports, or
port-port to specify a range of ports. You may also
combine a single range with a list, but the range must always be
specified first.The options available are:fragMatches if the packet is not the first fragment of
the datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma
separated list of options specified in
spec. The supported list of IP
options are: ssrr (strict
source route), lsrr (loose
source route), rr (record
packet route), and ts
(timestamp). The absence of a particular option may be
denoted with a leading !.establishedMatches if the packet is part of an already
established TCP connection (i.e. it has the RST or ACK
bits set). You can optimize the performance of the
firewall by placing established
rules early in the chain.setupMatches if the packet is an attempt to establish a
TCP connection (the SYN bit set is set but the ACK bit
is not).tcpflags flagsMatches if the TCP header contains the comma
separated list of flags. The
supported flags are fin,
syn, rst,
psh, ack, and
urg. The absence of a particular
flag may be indicated by a leading !.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types
separated by commas. Commonly used ICMP types are:
0 echo reply (ping reply),
+ 3 destination unreachable,
5 redirect, 8 echo request (ping request), and
11 time exceeded (used to
indicate TTL expiration as with
traceroute8).Listing the IPFW rulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is
the only way to see accounting counters.-tDisplay the last match times for each chain entry.
The time listing is incompatible with the input syntax
used by the ipfw8 utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW rulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny
policy will leave your system cut off from the network until
allow entries are added to the chain.Clearing the IPFW packet countersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example commands for ipfwThis command will deny all packets from the host
evil.crackers.org to the telnet port of the
host nice.people.org by being forwarded by
the router:&prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the
entire crackers.org network (a class C) to the
nice.people.org machine (any port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry
was matched with:&prompt.root; ipfw -at lBuilding a packet filtering firewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and I cannot tell
you how to build a firewall to meet your particular
requirements.When initially setting up your firewall, unless you have a
test bench setup where you can configure your firewall host in a
controlled environment, I strongly recommend you use the logging
version of the commands and enable logging in the kernel. This
will allow you to quickly identify problem areas and cure them
without too much disruption. Even after the initial setup phase is
complete, I recommend using the logging for of `deny' as it allows
tracing of possible attacks and also modification of the firewall
rules if your requirements alter.If you use the logging versions of the accept command, it can generate
large amounts of log data as one log line
will be generated for every packet that passes through the
firewall, so large ftp/http transfers, etc, will really slow the
system down. It also increases the latencies on those packets as
it requires more work to be done by the kernel before the packet
can be passed on. syslogd with also start using up a lot more
processor time as it logs all the extra data to disk, and it
could quite easily fill the partition
/var/log is located on.As currently supplied, FreeBSD does not have the ability to
load firewall rules at boot time. My suggestion is to put a call
to a shell script in the /etc/netstart
script. Put the call early enough in the netstart file so that the
firewall is configured before any of the IP interfaces are
configured. This means that there is no window during which time
your network is open.The actual script used to load the rules is entirely up to
you. There is currently no support in the ipfw utility for loading multiple rules in
the one command. The system I use is to use the command:&prompt.root; ipfw listto write a list of the current rules out to a file, and then
use a text editor to prepend ipfw
before all the lines. This will allow the script to
be fed into /bin/sh and reload the rules into the kernel. Perhaps
not the most efficient way, but it works.The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much
access to the outside world you want to allow from the inside.
Some general rules are:Block all incoming access to ports below 1024 for TCP.
This is where most of the security sensitive services are,
like finger, SMTP (mail) and telnet.Block all incoming UDP
traffic. There are very few useful services that travel over
UDP, and what useful traffic there is is normally a security
threat (e.g. Suns RPC and NFS protocols). This has its
disadvantages also, since UDP is a connectionless protocol,
denying incoming UDP traffic also blocks the replies to
outgoing UDP traffic. This can cause a problem for people
(on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
packets coming from ports 191 and 1525 to any internal UDP
port through the firewall. ntp is another service you may
consider allowing through, which comes from port 123.Block traffic to port 6000 from the outside. Port 6000
is the port used for access to X11 servers, and can be a
security threat (especially if people are in the habit of
doing xhost + on their
workstations). X11 can actually use a range of ports
starting at 6000, the upper limit being how many X displays
you can run on the machine. The upper limit as defined by
RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL
servers, etc). It is probably a good idea to block those as
well, as they normally fall outside the 1-1024 range
specified above.Another checklist for firewall configuration is available from
CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filteringAs I said above, these are only
guidelines. You will have to decide what
filter rules you want to use on your firewall yourself. I cannot
accept ANY responsibility if someone breaks into your network,
even if you follow the advice given above.
diff --git a/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
index b34fa0411c..85ff0bc7b4 100644
--- a/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
@@ -1,794 +1,838 @@
FreeBSD Project StaffThe FreeBSD Project is managed and operated by the following
groups of people:The FreeBSD Core TeamThe FreeBSD core team constitutes the project's “Board of
Directors”, responsible for deciding the project's overall goals
and direction as well as managing specific
areas of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.bde;&a.gibbs;&a.dg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.guido;&a.sos;&a.peter;&a.wollman;&a.joerg;The FreeBSD DevelopersThese are the people who have commit privileges and do the
engineering work on the FreeBSD source tree. All core team members
are also developers.&a.ugen;&a.mbarkah;&a.stb;&a.pb;&a.abial;&a.jb;&a.torstenb;&a.dburr;&a.charnier;&a.luoqi;&a.ejc;&a.kjc;&a.gclarkii;&a.archie&a.cracauer;&a.adam;&a.dillon;&a.dufault;&a.uhclem;&a.tegge;&a.eivind;&a.julian;&a.rse;&a.se;&a.sef;&a.fenner;&a.jfieber;&a.jfitz;&a.scrappy;&a.lars;
+
+ &.dirk;
+
+
&a.billf;
-
+
+
+ &a.gallatin;
+
+
&a.tg;&a.brandon;&a.graichen;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.thepish;&a.jhay;&a.helbig;&a.ghelmer;&a.erich;&a.nhibma;&a.flathill;
-
+
+
+ &a.foxfair;
+
+
&a.hosokawa;&a.hsu;&a.mph;&a.itojun;&a.mjacob;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.motoyuki;&a.jkoshy;&a.kuriyama;&a.grog;&a.jlemon;&a.truckman;&a.imp;&a.smace;&a.mckay;&a.mckusick;&a.ken;
-
+
+
+ &a.hm;
+
+
&a.tedm;&a.amurai;&a.markm;&a.max;&a.alex;
+
+ &a.newton;
+
+
&a.rnordier;&a.davidn;&a.obrien;&a.danny;&a.ljo;&a.fsmp;&a.smpatel;&a.wpaul;&a.jmacd;&a.wes;&a.steve;&a.mpp;&a.dfr;&a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.dima;&a.sada;&a.wosch;&a.ats;&a.jseger;
-
+
+
+ &a.simokawa;
+
+
&a.vanilla;&a.msmith;&a.des;&a.brian;
-
+
+
+ &a.mks;
+
+
&a.stark;&a.karl;&a.dt;&a.cwt;&a.pst;&a.hoek;&a.nectar;&a.swallace;&a.dwhite;&a.nate;&a.yokota;&a.jmz;&a.archie;The FreeBSD Documentation ProjectThe FreeBSD
Documentation Project is responsible for a number of
different services, each service being run by an individual and his
deputies (if any):Documentation Project Manager&a.nik;Webmaster&a.wosch;Handbook & FAQ Editor&a.faq;News Editor&a.nsj;Deputy: &a.john;FreeBSD Really-Quick NewsLetter EditorChris Coleman chrisc@vmunix.com
- Gallery and Commercial Editor
+ Gallery Editor&a.nsj;Deputy: &a.cawimm;
-
+
+
+ Commercial Editor
+
+
+ &a.mbarkah;
+
+
+
+
+ Web Changes Editor
+
+
+ &a.mbarkah;
+
+
+
Style Police & Art Director&a.opsys;Database Engineer&a.mayo;CGI Engineer&a.stb;Bottle Washing&a.nsj;LinuxDoc to DocBook conversion&a.nik;Who Is Responsible for WhatPrincipal Architect&a.dg;Documentation Project Manager&a.nik;Internationalization&a.ache;Networking&a.wollman;Postmaster&a.jmb;Release Coordinator&a.jkh;Public Relations & Corporate
Liaison&a.jkh;Security Officer&a.guido;>Source Repository ManagersPrincipal: &a.peter;Assistant: &a.jdp;International (Crypto): &a.markm;Ports Manager&a.asami;XFree86 Project, Inc. Liaison&a.rich;Usenet Support&a.joerg;GNATS Administrator&a.steve;Webmaster&a.wosch;
diff --git a/en_US.ISO_8859-1/books/porters-handbook/book.sgml b/en_US.ISO_8859-1/books/porters-handbook/book.sgml
index 092d021ad9..59c780838e 100644
--- a/en_US.ISO_8859-1/books/porters-handbook/book.sgml
+++ b/en_US.ISO_8859-1/books/porters-handbook/book.sgml
@@ -1,4523 +1,4673 @@
Installing Applications: The Ports collectionContributed by &a.jraynard;.The FreeBSD Ports collection allows you to compile and install a
very wide range of applications with a minimum of effort.For all the hype about open standards, getting a program to work
on different versions of Unix in the real world can be a tedious and
tricky business, as anyone who has tried it will know. You may be
lucky enough to find that the program you want will compile cleanly on
your system, install itself in all the right places and run flawlessly
“out of the box”, but this is unfortunately rather rare. With most
programs, you will find yourself doing a fair bit of head-scratching,
and there are quite a few programs that will result in premature
greying, or even chronic alopecia...Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but
they have an unfortunate tendency to triumphantly announce that your
system is something you have never heard of and then ask you lots of
questions that sound like a final exam in system-level Unix
programming (Does your system's gethitlist function return a const
pointer to a fromboz or a pointer to a const fromboz? Do you have
Foonix style unacceptable exception handling? And if not, why
not?).Fortunately, with the Ports collection, all the hard work
involved has already been done, and you can just type make install
and get a working program.Why Have a Ports Collection?The base FreeBSD system comes with a very wide range of tools
and system utilities, but a lot of popular programs are not in the
base system, for good reasons:-Programs that some people cannot live without and other
people cannot stand, such as a certain Lisp-based editor.Programs which are too specialised to put in the base
system (CAD, databases).Programs which fall into the “I must have a look at that
when I get a spare minute” category, rather than
system-critical ones (some languages, perhaps).Programs that are far too much fun to be supplied with a
serious operating system like FreeBSD ;-)However many programs you put in the base system, people
will always want more, and a line has to be drawn somewhere
(otherwise FreeBSD distributions would become absolutely
enormous).Obviously it would be unreasonable to expect everyone to port
their favourite programs by hand (not to mention a tremendous amount
of duplicated work), so the FreeBSD Project came up with an
ingenious way of using standard tools that would automate the
process.Incidentally, this is an excellent illustration of how “the
Unix way” works in practice by combining a set of simple but very
flexible tools into something very powerful.How Does the Ports Collection Work?Programs are typically distributed on the Internet as a
tarball consisting of a
Makefile and the source code for the program and usually some
instructions (which are unfortunately not always as instructive as
they could be), with perhaps a configuration script.The standard scenario is that you FTP down the tarball, extract
it somewhere, glance through the instructions, make any changes
that seem necessary, run the configure script to set things up and
use the standard make program to compile and install the program
from the source.FreeBSD ports still use the tarball mechanism, but use a
skeleton to hold the
"knowledge" of how to get the program working on FreeBSD,
rather than expecting the user to be able to work it out. They also
supply their own customised
Makefile, so that almost
every port can be built in the same way.If you look at a port skeleton (either on your FreeBSD
system or the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about the FTP site) and expect to find all sorts of pointy-headed rocket science lurking there, you may be disappointed by the one or two rather unexciting-looking files and directories you find there. (We will discuss in a minute how to go about Getting a port).“How on earth can this do anything?” I hear you cry. “There
is no source code there!”Fear not, gentle reader, all will become clear (hopefully).
Let's see what happens if we try and install a port. I have chosen
ElectricFence, a useful tool for developers, as the skeleton is
more straightforward than most.If you are trying this at home, you
will need to be root.&prompt.root; cd /usr/ports/devel/ElectricFence
&prompt.root; make install
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
===> Extracting for ElectricFence-2.0.5
===> Patching for ElectricFence-2.0.5
===> Applying FreeBSD patches for ElectricFence-2.0.5
===> Configuring for ElectricFence-2.0.5
===> Building for ElectricFence-2.0.5
[lots of compiler output...]
===> Installing for ElectricFence-2.0.5
===> Warning: your umask is "0002". If this is not desired, set it to
an appropriate value and install this port again by ``make reinstall''.
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
===> Compressing manual pages for ElectricFence-2.0.5
===> Registering installation for ElectricFence-2.0.5To avoid confusing the issue, I have completely removed the
build output.If you tried this yourself, you may well have got something like
this at the start:-&prompt.root; make install
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.The make program has noticed that you did not have a local
copy of the source code and tried to FTP it down so it could get the
job done. I already had the source handy in my example, so it did
not need to fetch it.Let's go through this and see what the make program was
doing.Locate the source code tarball. If it is not available locally, try to
grab it from an FTP site.Run a checksum
test on the tarball to make sure it has not been tampered
with, accidentally truncated, downloaded in ASCII mode, struck
by neutrinos while in transit, etc.Extract the tarball into a temporary work directory.Apply any patches
needed to get the source to compile and run under FreeBSD.Run any configuration script required by the build
process and correctly answer any questions it asks.(Finally!) Compile the code.Install the program executable and other supporting
files, man pages, etc. under the
/usr/local hierarchy, where they will not
get mixed up with system programs. This also makes sure that
all the ports you install will go in the same place, instead
of being flung all over your system.Register the installation in a database. This means that,
if you do not like the program, you can cleanly remove all traces of it from
your system.Scroll up to the make output and see if you can match these
steps to it. And if you were not impressed before, you should be by
now!Getting a FreeBSD PortThere are two ways of getting hold of the FreeBSD port for a
program. One requires a FreeBSD
CDROM, the other involves using an Internet Connection.Compiling ports from CDROMAssuming that your FreeBSD CDROM is in the drive and mounted on
/cdrom (and the mount point
must be /cdrom), you should
then be able to build ports just as you normally do and the port
collection's built in search path should find the tarballs in
/cdrom/ports/distfiles/ (if they exist there)
rather than downloading them over the net.
-
+
+ Another way of doing this, if you want to just use the port
+ skeletons on the CDROM, is to set these variables in
+ /etc/make.conf:
+
+
+PORTSDIR= /cdrom/ports
+DISTDIR= /tmp/distfiles
+WRKDIRPREFIX= /tmp
+
+ Substitute /tmp for any place you have enough
+ free space. Then, just cd to the appropriate
+ subdirectory under /cdrom/ports and type
+ make install as
+ usual. WRKDIRPREFIX will cause the port to be
+ build under /tmp/cdrom/ports; for instance,
+ games/oneko will be built under
+ /tmp/cdrom/ports/games/oneko.
+
There are some ports for which we cannot provide the
original source in the CDROM due to licensing limitations. In
that case, you will need to look at the section on Compiling ports using an Internet connection.Compiling ports from the InternetIf you do not have a CDROM, or you want to make sure you get
the very latest version of the port you want, you will need to
download the
skeleton for the port. Now
this might sound like rather a fiddly job full of pitfalls, but
it is actually very easy.First, if you are running a release version of FreeBSD, make
sure you get the appropriate “upgradekiet” for your
replease from the ports
web page. These packages include files that have been
updated since the release that you may need to compile new
ports.The key to the skeletons is that the FreeBSD FTP server can create
on-the-fly
tarballs for you. Here is
how it works, with the gnats program in the databases directory as
an example (the bits in square brackets are comments. Do not type
them in if you are trying this yourself!):-&prompt.root; cd /usr/ports
&prompt.root; mkdir databases
&prompt.root; cd databases
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports/databases
+>cd /pub/FreeBSD/ports/ports/databases>get gnats.tar
[tars up the gnats skeleton for us]
>quit
&prompt.root; tar xf gnats.tar
[extract the gnats skeleton]
&prompt.root; cd gnats
&prompt.root; make install
[build and install gnats]What happened here? We connected to the FTP server in the
usual way and went to its databases sub-directory. When we gave it
the command get gnats.tar, the FTP server tarred up the gnats directory for us.We then extracted the gnats skeleton and went into the gnats
directory to build the port. As we explained earlier, the make process noticed we did not have a
copy of the source locally, so it fetched one before extracting,
patching and building it.Let's try something more ambitious now. Instead of getting a
single port skeleton, let's get a whole sub-directory, for example
all the database skeletons in the ports collection. It looks
almost the same:-&prompt.root; cd /usr/ports
&prompt.root; ftp ftp.freebsd.org
[log in as `ftp' and give your email address when asked for a
password. Remember to use binary (also known as image) mode!]
->cd /pub/FreeBSD/ports
+>cd /pub/FreeBSD/ports/ports>get databases.tar
[tars up the databases directory for us]
>quit
&prompt.root; tar xf databases.tar
[extract all the database skeletons]
&prompt.root; cd databases
&prompt.root; make install
[build and install all the database ports]With half a dozen straightforward commands, we have now got a
set of database programs on our FreeBSD machine! All we did that
was different from getting a single port skeleton and building it
was that we got a whole directory at once, and compiled everything
in it at once. Pretty impressive, no?If you expect to be installing many ports, it is probably
worth downloading all the ports directories.SkeletonsA team of compulsive hackers who have forgotten to eat in a
frantic attempt to make a deadline? Something unpleasant lurking in
the FreeBSD attic? No, a skeleton here is a minimal framework that
supplies everything needed to make the ports magic work.MakefileThe most important component of a skeleton is the Makefile.
This contains various statements that specify how the port should
be compiled and installed. Here is the Makefile for
ElectricFence:-
# New ports collection makefile for: Electric Fence
# Version required: 2.0.5
# Date created: 13 November 1997
# Whom: jraynard
#
# $Id$
#
DISTNAME= ElectricFence-2.0.5
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_SUNSITE}
MASTER_SITE_SUBDIR= devel/lang/c
MAINTAINER= jraynard@freebsd.org
MAN3= libefence.3
do-install:
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
.include <bsd.port.mk>The lines beginning with a "#" sign are comments for
the benefit of human readers (as in most Unix script
files).DISTNAME specifies the name of the tarball, but without the
extension.CATEGORIES states what kind of program this is. In
this case, a utility for developers. See the categories section of this
handbook for a complete list.MASTER_SITES is the URL(s) of the master FTP site,
which is used to retrieve the tarball if it is not available on the local system.
This is a site which is regarded as reputable, and is normally the
one from which the program is officially distributed (in so far
as any software is "officially" distributed on the
Internet).MAINTAINER is the email address of the person who is
responsible for updating the skeleton if, for example a new
version of the program comes out.Skipping over the next few lines for a minute, the line
.include <bsd.port.mk> says
that the other statements and commands needed for this port are
in a standard file called bsd.port.mk. As
these are the same for all ports, there is no point in duplicating
them all over the place, so they are kept in a single standard
file.This is probably not the place to go into a detailed
examination of how Makefiles work; suffice it to say that the line
starting with MAN3 ensures that the ElectricFence man page is
compressed after installation, to help conserve your precious disk
space. The original port did not provide an install target,
so the three lines from do-install ensure that the files
produced by this port are placed in the correct
destination.The files directoryThe file containing the checksum for the port is called
md5, after the MD5 algorithm used for ports
checksums. It lives in a directory with the slightly confusing
name of files.This directory can also contain other miscellaneous files that
are required by the port and do not belong anywhere else.The patches directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The pkg directoryThis program contains three quite useful files:-COMMENT — a one-line description of
the program.DESCR — a more detailed description.PLIST — a list of all the files
that will be created when the program is installed.What to do when a port does not work.Oh. You can do one of four (4) things :Fix it yourself. Technical details on how ports work can
be found in
Porting applications.Gripe. This is done by e-mail only! Send such e-mail to
the &a.ports; and please include the name/version of the port,
where you got both the port source & distfile(s) from, and
what the text of the error was.Forget it. This is the easiest for most — very few of the
programs in ports can be classified as essential!Grab the pre-compiled package from a ftp server. The
“master” package collection is on FreeBSD's FTP server in
the packages
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/">packages
directory, though check your local mirror first,
please! These are more likely to work (on the whole) than
trying to compile from source and a lot faster besides! Use
the pkg_add1 program to install a
package file on your system.Some Questions and AnswersQ. I thought this was going to be a discussion about
modems??!A. Ah. You must be thinking of the serial ports on the
back of your computer. We are using “port” here to mean the
result of “porting” a program from one version of Unix to
another. (It is an unfortunate bad habit of computer people to
use the same word to refer to several completely different
things).Q. I thought you were supposed to use packages to install
extra programs?A. Yes, that is usually the quickest and easiest way of
doing it.Q. So why bother with ports then?A. Several reasons:-The licensing conditions on some software
distributions require that they be distributed as source
code, not binaries.Some people do not trust binary distributions. At
least with source code you can (in theory) read through
it and look for potential problems yourself.If you have some local patches, you will need the
source to add them yourself.You might have opinions on how a program should be
compiled that differ from the person who did the package
— some people have strong views on what optimisation
setting should be used, whether to build debug versions
and then strip them or not, etc. etc.Some people like having code around, so they can
read it if they get bored, hack around with it, borrow
from it (licence terms permitting, of course!) and so
on.If you ain't got the source, it ain't software!
;-) Q. What is a patch?A. A patch is a small (usually) file that specifies how to
go from one version of a file to another. It contains text
that says, in effect, things like “delete line 23”, “add
these two lines after line 468” or “change line 197 to
this”. Also known as a “diff”, since it is generated by a
program of that name. Q. What is all this about
tarballs?A. It is a file ending in .tar or
.tar.gz (with variations like
.tar.Z, or even .tgz
if you are trying to squeeze the names into a DOS
filesystem).Basically, it is a directory tree that has been archived
into a single file (.tar) and optionally
compressed (.gz). This technique was
originally used for Tape
ARchives (hence the name tar), but it is
a widely used way of distributing program source code around
the Internet.You can see what files are in them, or even extract them
yourself, by using the standard Unix tar program, which comes
with the base FreeBSD system, like this:-&prompt.user; tar tvzf foobar.tar.gz
&prompt.user; tar xzvf foobar.tar.gz
&prompt.user; tar tvf foobar.tar
&prompt.user; tar xvf foobar.tar Q. And a checksum?A. It is a number generated by adding up all the data in
the file you want to check. If any of the characters change,
the checksum will no longer be equal to the total, so a simple
comparison will allow you to spot the difference. (In
practice, it is done in a more complicated way to spot
problems like position-swapping, which will not show up with a
simplistic addition).Q. I did what you said for compiling ports from a CDROM and it worked great
until I tried to install the kermit port:-&prompt.root; make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.Why can it not be found? Have I got a dud CDROM?A. The licensing terms for kermit do not allow us to put
the tarball for it on the CDROM, so you will have to fetch it
by hand — sorry! The reason why you got all those error
messages was because you were not connected to the Internet at
the time. Once you have downloaded it from any of the sites
above, you can re-start the process (try and choose the
nearest site to you, though, to save your time and the
Internet's bandwidth).Q. I did that, but when I tried to put it into
/usr/ports/distfiles I got some error
about not having permission.A. The ports mechanism looks for the tarball in
/usr/ports/distfiles, but you will not be
able to copy anything there because it is sym-linked to the
CDROM, which is read-only. You can tell it to look somewhere
else by doing&prompt.root; make DISTDIR=/where/you/put/it installQ. Does the ports scheme only work if you have everything
in /usr/ports? My system administrator
says I must put everything under
/u/people/guests/wurzburger, but it does
not seem to work.A. You can use the PORTSDIR and PREFIX variables to tell
the ports mechanism to use different directories. For
instance,&prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports installwill compile the port in
/u/people/guests/wurzburger/ports and
install everything under /usr/local.&prompt.root; make PREFIX=/u/people/guests/wurzburger/local installwill compile it in /usr/ports and
install it in
/u/people/guests/wurzburger/local.And of course&prompt.root; make PORTSDIR=.../ports PREFIX=.../local installwill combine the two (it is too long to fit on the page if
I write it in full, but I am sure you get the idea).If you do not fancy typing all that in every time you
install a port (and to be honest, who would?), it is a good
idea to put these variables into your environment.Q. I do not have a FreeBSD CDROM, but I would like to have
all the tarballs handy on my system so I do not have to wait
for a download every time I install a port. Is there an easy
way to get them all at once?A. To get every single tarball for the ports collection,
do&prompt.root; cd /usr/ports
&prompt.root; make fetchFor all the tarballs for a single ports directory,
do&prompt.root; cd /usr/ports/directory
&prompt.root; make fetchand for just one port — well, I think you have guessed
already.Q. I know it is probably faster to fetch the tarballs from
one of the FreeBSD mirror sites close by. Is there any way to
tell the port to fetch them from servers other than ones
listed in the MASTER_SITES?A. Yes. If you know, for example, ftp.FreeBSD.ORG is much
closer than sites listed in MASTER_SITES, do as following
example.&prompt.root; cd /usr/ports/directory
-&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
+&prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetchQ. I want to know what files make is going to need before
it tries to pull them down.A. make fetch-list will display a list of the files
needed for a port.Q. Is there any way to stop the port from compiling? I
want to do some hacking on the source before I install it, but
it is a bit tiresome having to watch it and hit control-C
every time.A. Doing make extract will stop it after it has fetched
and extracted the source code.Q. I am trying to make my own port and I want to be able
to stop it compiling until I have had a chance to see if my
patches worked properly. Is there something like make
extract, but for patches?A. Yep, make patch is what you want. You will probably
find the PATCH_DEBUG option useful as well. And by the way,
thank you for your efforts!Q. I have heard that some compiler options can cause bugs.
Is this true? How can I make sure that I compile ports with
the right settings?A. Yes, with version 2.6.3 of gcc (the version shipped
with FreeBSD 2.1.0 and 2.1.5), the option could result in
buggy code unless you used the option as
well. (Most of the ports don't use ). You
should be able to specify the compiler
options used by something like&prompt.root; make CFLAGS='-O2 -fno-strength-reduce' installor by editing /etc/make.conf, but
unfortunately not all ports respect this. The surest way is to
do make configure, then go into the source directory and
inspect the Makefiles by hand, but this can get tedious if the
source has lots of sub-directories, each with their own
Makefiles.Q. There are so many ports it is hard to find the one I
want. Is there a list anywhere of what ports are available?A. Look in the INDEX file in
/usr/ports. If you would like to search the
ports collection for a keyword, you can do that too. For example,
you can find ports relevant to the LISP programming language
using:&prompt.user; cd /usr/ports
&prompt.user; make search key=lispQ. I went to install the foo port but the system
suddenly stopped compiling it and starting compiling the
bar
port. What's going on?A. The foo port needs something that is supplied with
bar — for instance, if foo uses graphics, bar might have
a library with useful graphics processing routines. Or bar
might be a tool that is needed to compile the foo
port. Q. I installed the grizzle
program from the ports and frankly it is a complete waste of
disk space. I want to delete it but I do not know where it put
all the files. Any clues?A. No problem, just do&prompt.root; pkg_delete grizzle-6.5
Q. Hang on a minute, you have to know the version number to
use that command. You do not seriously expect me to remember
that, do you??A. Not at all, you can find it out by doing&prompt.root; pkg_info -a | grep grizzle
Information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.Q. Talking of disk space, the ports directory seems to be
taking up an awful lot of room. Is it safe to go in there and
delete things?A. Yes, if you have installed the program and are fairly
certain you will not need the source again, there is no point
in keeping it hanging around. The best way to do this
is&prompt.root; cd /usr/ports
&prompt.root; make cleanwhich will go through all the ports subdirectories and
delete everything except the skeletons for each port.Q. I tried that and it still left all those tarballs or
whatever you called them in the distfiles
directory. Can I delete those as well?A. Yes, if you are sure you have finished with them, those
can go as well.Q. I like having lots and lots of programs to play with.
Is there any way of installing all the ports in one go?A. Just do&prompt.root; cd /usr/ports
&prompt.root; make installQ. OK, I tried that, but I thought it would take a very
long time so I went to bed and left it to get on with it. When
I looked at the computer this morning, it had only done three
and a half ports. Did something go wrong?A. No, the problem is that some of the ports need to ask
you questions that we cannot answer for you (eg “Do you want
to print on A4 or US letter sized paper?”) and they need to
have someone on hand to answer them.Q. I really do not want to spend all day staring at the
monitor. Any better ideas?A. OK, do this before you go to bed/work/the local
park:-&prompt.root cd /usr/ports
&prompt.root; make -DBATCH installThis will install every port that does
not require user input. Then, when you
come back, do&prompt.root; cd /usr/ports
&prompt.root; make -DIS_INTERACTIVE installto finish the job.Q. At work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do
what we need. Is there any way of making our own packages, so
we can distribute it more easily around our sites?A. No problem, assuming you know how to make patches for
your changes:-&prompt.root; cd /usr/ports/somewhere/frobble
&prompt.root; make extract
&prompt.root; cd work/frobble-2.8
[Apply your patches]
&prompt.root; cd ../..
&prompt.root; make packageQ. This ports stuff is really clever. I am desperate to
find out how you did it. What is the secret?A. Nothing secret about it at all, just look at the
bsd.ports.mk and
bsd.ports.subdir.mk files in your makefiles
directory.Readers with an aversion to intricate shell-scripts are
advised not to follow this link...)Making a port yourselfContributed by &a.jkh;, &a.gpalmer;, &a.asami;
&a.obrien; and &a.hoek;. 28 August 1996.So, now you are interested in making your own port?
Great!What follows are some guidelines for creating a new port for
FreeBSD. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Only a fraction of the overridable variables
(VAR) are mentioned
in this document. Most (if not all) are documented at the start of
bsd.port.mk. This file users a non-standard
tab setting. Emacs and
Vim should recognise the setting on
loading the file. vi or ex
can be set to use the correct value by typing :set
tabstop=4 once the file has been loaded.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into DISTDIR, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the MakefileThe minimal Makefile would
look something like this:
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# $Id$
#
DISTNAME= oneko-1.1b
CATEGORIES= games
MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG
MAN1= oneko.1
MANCOMPRESSED= yes
USE_IMAKE= yes
.include <bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the sample Makefile
section.Writing the description filesThere are three description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.COMMENTThis is the one-line description of the port.
Please do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the screen.DESCRThis is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual or an
in-depth description on how to use or compile the port!
Please be careful if you are copying from the
README or manpage; too often
they are not a concise description of the port or are in an
awkward format (e.g., manpages have justified spacing). If the
ported software has an official WWW homepage, you should list
it here.It is recommended that you sign the name at the end of
this file, as in:
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
http://www.oneko.org/
- Satoshi
asami@cs.berkeley.eduPLISTThis file lists all the files installed by the port. It
is also called the “packing list” because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). If you are using the
MANn variables (as
you should be), do not list any manpages here.Here is a small example:
bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/onekoRefer to the pkg_create1 man page
for details on the packing list.You should list all the files, but not the name
directories, in the list. Also, if the port creates
directories for itself during installtion, make sure to add
@dirrm lines as necessary to remove them
when the port is deleted.It is recommended that you keep all the filenames in
this file sorted alphabetically. It will make verifying the
changes when you upgrade the port much easier.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. These are
the important points you need to verify.PLIST does not contain anything not
installed by your portPLIST contains everything that is
installed by your portYour port can be installed multiple times using the
reinstall targetYour port cleans
up after itself upon deinstallRecommended test orderingmake installmake packagemake deinstallpkg_add `make package-name`make deinstallmake reinstallmake packageMake sure that there aren't any warnings issued in any of
the package and
deinstall stages, After step 3, check
to see if all the new directories are correctly deleted. Also,
try using the software after step 4, to ensure that is works
correctly when installed from a package.Checking your port with portlintPlease use portlint to see if your port
conforms to our guidelines. The portlint
program is part of the ports collection. In particular, your may
want to check if the Makefile is in the right
shape and the package is
named appropriately.Submitting the portFirst, make sure you have read the Do's and Dont's section.Now that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. We do not need your
work directory or the
pkgname.tgz package, so delete them
now. Next, simply include the output of shar `find
port_dir` in a bug report and send it with the
send-pr1 program (see Bug
Reports and General Commentary for more information
about send-pr1. If the uncompressed port is larger than
20KB, you should compress it into a tarfile and use uuencode1 before including it in the bug report (uuencoded
tarfiles are acceptable even if the bug report is smaller than
20KB but are not preferred). Be sure to classify the bug report as
category ports and class
change-request. (Do not mark the report
confidential!)One more time, do not include the original source
distfile, the work directory, or the
package you built with make
package.In the past, we asked you to upload new port submissions
in our ftp site (ftp.freebsd.org). This is no longer
recommended as read access is turned off on that
incoming/ directory of that site due to
the large amount of pirated software showing up there.We will look at your port,
get back to you if necessary, and put it in the
tree. Your name will also appear in the list of “Additional
FreeBSD contributors” on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in DISTDIR.
If fetch cannot find the required files in DISTDIR it will look up the
URL MASTER_SITES,
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed.
The extract target is run. It looks for your port's
distribution file (typically a gzip'd tarball) in DISTDIR and unpacks it into a temporary subdirectory
specified by WRKDIR
(defaults to work).The patch target is run. First, any patches defined
in PATCHFILES are
applied. Second, if any patches are found in PATCHDIR (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.The configure target is run. This can do any one of
many different things.If it exists,
scripts/configure is run.If HAS_CONFIGURE or
GNU_CONFIGURE
is set,
WRKSRC/configure is
run.If USE_IMAKE is set,
XMKMF
(default: xmkmf
-a) is run.The build target is run. This is responsible for
- descending into the ports' private working directory
+ descending into the port's private working directory
(WRKSRC) and
building it. If USE_GMAKE is set, GNU
make will be used,
otherwise the system make
will be used.The above are the default actions. In addition, you can
define targets pre-something or post-something, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-something. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-something target in
your Makefile.The “main” targets (e.g., extract, configure, etc.) do nothing more than
- make sure all the stages up to that one is completed and
+ make sure all the stages up to that one are completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (foo.tar.gz or
foo.tar.Z) and copy it into
DISTDIR. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, you might want to put a copy on a
reliable ftp or http server that you control (e.g., your home
page). Make sure you set MASTER_SITES to
reflect your choice.If you
cannot find somewhere convenient and reliable to put the distfile
(if you are a FreeBSD committer, you can just put it in your
public_html/ directory on
freefall),
we can “house” it ourselves by putting
- it on ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
+ it on ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as MASTER_SITE_LOCAL. Send mail to
the &a.ports;if you are not sure what to do.If your port's distfile changes all the time for no good
reason, consider putting the distfile in your home page and
listing it as the first MASTER_SITES. This
will prevent users from getting checksum
mismatch errors, and also reduce the workload of
maintainers of our ftp site. Also, if there isonly one master
site for the port, it is recommended that you house a backup at
your site and list it as the second
MASTER_SITES.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
DISTDIR. Do not worry if
- they come from site other than where you got the main source
+ they come from a site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of PATCHFILES below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as “plug-and-play”
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-xx where
xx denotes the sequence in which
the patches will be applied — these are done in
alphabetical order, thus
aa first, ab second and so on. These files
should be stored in PATCHDIR, from where they will be
automatically applied. All patches should be relative to
WRKSRC (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier,
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing WRKSRC/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow “overnight builds” to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).It is also recommended that if there are reasonable default
answers to the questions, you check the
PACKAGE_BUILDING variable and turn off the
interactive script when it is set. This will allow us to build
the packages for CD-ROMs and ftp.Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a sample
Makefile in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in DISTDIR as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set DISTNAME to be the base name of
your port. The default rules expect the distribution file
list (DISTFILES) to be
named DISTNAMEEXTRACT_SUFX which, if it is a normal tarball, is going to be
something like foozolix-1.0.tar.gz for a setting of DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/DISTNAME, e.g. work/foozolix-1.0/.All this behavior can be overridden, of course; it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set DISTFILES explicitly. If only a
subset of DISTFILES are
actual extractable archives, then set them up in EXTRACT_ONLY, which will override
the DISTFILES list when
it comes to extraction, and the rest will be just left in
DISTDIR for later
use.PKGNAMEIf DISTNAME does not conform to our guidelines for a good package
name, you should set the PKGNAME
variable to something better. See the abovementioned guidelines
for more details.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable CATEGORIES. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories and pick the
ones that are suitable for your port.This list also determines where in the ports tree the port
is imported. If you put more than one category here, it is
assumed that the port files will be put in the subdirectory with
the name in the first category. See the categories section for
more discussion about how to pick the right categories.If you port truly belongs to something that is different
from all the existing ones, you can even create a new category
name. In that case, please send mail to the &a.ports; to propose
a new category.There is no error checking for category
names. make package will happily create a
new directory if you mustype the category name, so be
careful!MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in MASTER_SITES. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with FETCH if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set PATCHFILES to the names of the
files and PATCH_SITES to
the URL of the directory that contains them (the format is the
same as MASTER_SITES).If the patch is not relative to the top of the source tree
(i.e., WKRSRC) because it
contains some extra pathnames, set PATCH_DIST_STRIP accordingly.
- For instance, if all the pathnames in the patch has an extra
+ For instance, if all the pathnames in the patch have an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
PATCHFILES. If that is
the case, add the name and the location of the patch tarball
to DISTFILES and
MASTER_SITES. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the PATCHDIR directory and calling it
patch-xx.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to MAINTAINER
on Makefiles section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine. There are also some
pre-supported dependency variables for common cases, plus a few
more to control the behaviour of dependencies.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir:target tuples where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available, and
target is the target to call in
that directory. For example,
LIB_DEPENDS= jpeg\\.9\\.:${PORTSDIR}/graphics/jpeg:install
will check for a shared jpeg library with
major version 9, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found. The target part can be
omitted if it is equal to DEPENDS_TARGET
(which defaults to install).The lib part is an argument
given to ldconfig -r | grep -wF. There
shall be no reqular expressions in this variable.The dependency is checked twice, once from within the
extract target and then from within
the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir:target tuples where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available, and
target is the target to call in
that directory. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish8.0:${PORTSDIR}/x11-toolkits/tk80
will check if the file or directory
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish8.0 is in your search path, and
descend into the x11-toolkits/tk80 subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system. The
target part can be omitted if it is
the same DEPENDS_TARGET.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir:target tuples.
For example,
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.“build” here means everything from extracting to
compilation. The dependency is checked from within the
extract target. The
target part can be omitted if it
is the same as DEPENDS_TARGETFETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir:target tuples. For
example,
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2
will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the
fetch target. The
target part can be omitted if it is
the same as DEPENDS_TARGET.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted in addition to having
them installed, then use this variable. This is a list of
dir:target, as there is nothing to check, unlike the previous four. The target part can be omitted if it is the same as DEPENDS_TARGET.Common dependency variablesDefine USE_XLIB=yes if your port
requires the X Window System to be installed (it is implied by
USE_IMAKE). Define
USE_GMAKE=yes if your port requires GNU
make instead of BSD
make. Define
USE_AUTOCONF=yes if your port requires GNU
autoconf to be run. Define USE_QT=yes if
your port uses the latest qt toolkit. Use
USE_PERL5=yes if your port requires version
5 of the perl language. (The last is especially important since
some versions of FreeBSD has perl5 as part of the base system
while others don't.)Notes on dependenciesAs mentioned above, the default target to call when a
dependency is required is
DEPENDS_TARGET. It defaults to
install. This is a user variable; is is
never defined in a port's Makefile. If
your port needs a special way to handle a dependency, use the
:target part of the
*_DEPENDS variables instead of redefining
DEPENDS_TARGET.When you type make clean, its
dependencies are automatically cleaned too. If you do not wish
this to happen, define the variable
NOCLEANDEPENDS in your environment.To depend on another port unconditionally, it is customary
to use the string nonexistent as the first
field of BUILD_DEPENDS or
RUN_DEPENDS. Use this only when you need to
the to get to the source of the other port. You can often save
compilation time by specifying the target too. For
instance
BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract
will always descend to the JPEG port and extract it.Do not use DEPENDS unless there is no
other way the behaviour you want can be accomplished. It will
cause the other port to be always build (and installed, by
default), and the dependency will go into the packages as
- well. If this is really what you need, I recommend you to
+ well. If this is really what you need, I recommend you
write it as BUILD_DEPENDS and
RUN_DEPENDS instead—at least the
intention will be clear.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses
configure, set
HAS_CONFIGURE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes (this implies
HAS_CONFIGURE). If you want to give some
extra arguments to configure (the default
argument list --prefix=${PREFIX} for
GNU configure and empty for non-GNU
configure), set those extra arguments in
CONFIGURE_ARGS. If your package uses GNU
autoconf, set
USE_AUTOCONF=yes. This implies
GNU_CONFIGURE, and will cause
autoconf to be run before
configure.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.
If the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>If your port's source Makefile has
something else than all as the main
build target, set ALL_TARGET
accordingly. Same goes for install and
INSTALL_TARGET.Special considerationsThere are some more things you have to take into account when
you create a port. This section explains the most common of
those.ldconfigIf your port installs a shared library, add a
post-install target to your
Makefile that runs
${LDCONFIG} -m on the directory where
the new library is installed (usually
PREFIX/lib) to register
it into the shared library cache.Also, add a matching @exec /sbin/ldconfig
-m and @unexec /sbin/ldconfig -R
pair to your pkg/PLIST file so that a user
who installed the package can start using teh shared libraru
immediately and deinstallation will not cause the system to
still believe the library is there. These lines should
immediately follow the line for the shared library itself, as
in:
lib/libtvl80.so.1
@exec /sbin/ldconfig -m %D/lib
@unexec /sbin/ldconfig -RNever, ever, ever add a line that says
ldconfig without any arguments to your
Makefile or
pkg/PLIST. This will reset the shared
libraru cache to the contents of /usr/lib
only, and will royally screw up the user's machine ("Help, xinit
does not run anymore after I install this port!"). Anybody who
does this will be shot and cut in 65,536 pieces by a rusty knife
and have is liver chopped out by a bunch of crows and will
eternally rot to death in the deepest bowels of hell (not
necessarily in that order…)ELF support
- Since FreeBSD is moving to ELF from 3.0-release onwards,
+ Since FreeBSD is moving to ELF shortly after 3.0-release,
we need to convert many ports that build shared libraries
to support ELF. Complicating this task is that a 3.0
system can run as both ELF and a.out, and that there will
be one more release (2.2.8) from the 2.2 branch. Below
are the guidelines on how to convert a.out only ports to
support both a.out and ELF compilation.Some part of this list is only applicable during the
conversion, but will be left here for awhile for reference
in case you have come across some old port you wish to
upgrade.Moving a.out libraries out of the wayA.out libraries should be moved out of
/usr/local/lib and similar to an
aout subdirectory. (If you don't move them
out of the way, ELF ports will happily overwrite a.out libraries.)
The move-aout-libs target in the -current
src/Makefile (called from
aout-to-elf) will do this for you. It
will only move a.out libs so it is safe to call it on a system
with both ELF and a.out libs in the standard directories.FormatThe ports tree will build packages in the format the machine
is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending
on what `objformat` returns. Also, once users
move a.out libraries to a subdirectory, building a.out libraries
will be unsupported. (I.e., it may still work if you know what you
are doing, but you are on your own.)If a port only works for a.out, set
BROKEN_ELF to a string describing the reason
why. Such ports will be skipped during a build on an ELF
system.PORTOBJFORMATbsd.port.mk will set
PORTOBJFORMAT to aout or
elf and export it in the environments
CONFIGURE_ENV, SCRIPTS_ENV and
MAKE_ENV. (It's always going to be
aout in -stable). It is also passed to
PLIST_SUB as
PORTOBJFORMAT=${PORTOBJFORMAT}. (See comment
on ldconfig lines below.)The variable is set using this line in
bsd.port.mk:
PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aoutPorts' make processes should use this variable to decide what
to do. However, if the port's configure
script already automatically detects an ELF system, it is not
necessary to refer to PORTOBJFORMAT.Building shared librariesThe following are differences in handling shared
libraries for a.out and ELF.Shared library versionsAn ELF shared library should be called
libfoo.so.M
where M is the single version
number, and an a.out library should be called
libfoo.so.M.N where M is the major version and N is the the minor version number. Do not mix those; never install an ELF shared library called libfoo.so.N.M or an a.out shared library (or symlink) called libfoo.so.N.Linker command linesAssuming cc -shared is used rather than
ld directly, the only difference is that
you need to add
on the command line for ELF.You need to install a symlink from
libfoo.so to
libfoo.so.N to
make ELF linkers happy. Since it should be listed in
PLIST too, and it won't hurt in the a.out
case (some ports even require the link for dynamic loading), you
should just make this link regardless of the setting of
PORTOBJFORMAT.LIB_DEPENDSAll port Makefiles are edited to remove minor numbers from
LIB_DEPENDS, and also to have the regexp
support removed. (E.g., foo\\.1\\.\\(33|40\\)
becomes foo.2.) They will be matched using
grep -wF.PLISTPLIST should contain the short (ELF)
shlib names if the a.out minor number is zero, and the long
(a.out) names otherwise. bsd.port.mk will
automatically add .0 to the end of short shlib
lines if PORTOBJFORMAT equals
aout, and will delete the minor number from
long shlib names if PORTOBJFORMAT equals
elf.In cases where you really need to install shlibs with two
versions on an ELF system or those with one version on an a.out
system (for instance, ports that install compatibility libraries
for other operating systems), define the variable
NO_FILTER_SHLIBS. This will turn off the
editing of PLIST mentioned in the previous
paragraph.ldconfigThe ldconfig line in Makefiles should read:
${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....In PLIST it should read;
@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ...
@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -RThis is to ensure that the correct ldconfig
will be called depending on the format of the package, not the
default format of the system.MASTERDIRIf your port needs to build slightly different versions of
packages by having a variable (for instance, resolution, or paper
size) take different values, create one subdirectory per package
to make it easier forusers to see what to do, but try to share as
many files as possible between ports. Typically you only need a
very short Makefile in all but one of the
directories if you use variables cleverly. In the sole
Makefiles, you can use
MASTERDIR to specify the directory where the
rest of the files are. Also, use a variable as part of
PKGNAME
so the packages will have different names.This will be best demonstrated by an example. This is part of
japanese/xdvi300/Makefile;
PKGNAME= ja-xdvi${RESOLUTION}-17
:
# default
RESOLUTION?= 300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
${RESOLUTION} != 300 && ${RESOLUTION} != 400
@${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
@${ECHO} "Possible values are: 118, 240, 300 (default) and 400."
@${FALSE}
.endifjapanese/xdvi300 also has all the regular
patches, package files, etc. If you type make
there, it will take the default value for the resolution (300) and
build the port normally.As for other resolutions, this is the
entirexdvi118/Makefile;
RESOLUTION= 118
MASTERDIR= ${.CURDIR}/../xdvi300
.include ${MASTERDIR}/Makefile(xdvi240/Makefile and
xdvi400/Makefile are similar). The
MASTERDIR definition tells
bsd.port.mk that the refulat set of
subdirectories like PATCHDIR and
PKGDIR are to be found under
xdvi300. The
RESOLUTION=118 line will override the
RESOLUTION=300 line in
xdvi300/Makefile and the port will be built
with resolution set to 118.Shared library versionsFirst, please read our policy
on shared library versioning to understand
what to do with shared library versions in general. Do
not blindly assume software authors know what they are
doing; many of them do not. It is very important that
these details are carefully considered, as we have quite a
unique situation where we are trying to have dozens of
potentially incompatible software pairs co-exist.
Careless port imports have caused great trouble regarding
shared libraries in the past (ever wondered why the port
jpeg-6b has a shared library version of 9.0?).
If in doubt, send a message to the &a.ports;. Most of the
time, your job ends by determining the right shared
library version and making appropriate patches to
implement it.However, if there is a port which is a different version
of the same software already in the tree, the situation is
much more complex. In short, the FreeBSD implementation
does not allow the user to specify to the linker which
version of shared library to link against (the linker will
always pick the highest numbered version). This means, if
there is a libfoo.so.3.2 and libfoo.so.4.0 in
the system, there is no way to tell the linker to link a
particular application to libfoo.so.3.2. It is
essentially completely overshadowed in terms of
compilation-time linkage. In this case, the only solution
is to rename the base part of the shared library. For
instance, change libfoo.so.4.0 to
libfoo4.so.1.0 so both version 3.2 and 4.0 can be
linked from other ports.ManpagesThe MAN[1-9LN] variables will automatically
add any manpages to pkg/PLIST (this means you
must not list manpages in the
PLIST—see generating PLIST for more). It
also makes the install stage automatically compress or uncompress
manpages depending on the setting of
NOMANCOMPRESS in
/etc/make.conf.To specify whether the manpages are compressed upon
installation, use the MANCOMPRESSED variable.
This variable can take three values, yes,
no and maybe.
yes means manpages are already installed
compressed, no means they are not, and
maybe means the software already respects the
value of NOMANCOMPRESS so
bsd.port.mk does not have to do anything
special.MANCOMPRESSED is automatically set to
yes if USE_IMAKE is set and
NO_INSTALL_MANPAGES is not set, and to
no otherwise. You don't have to explicitly
define it unless the default is not suitable for your port.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages in
certain sections go in a non-standard place, such as some Perl
modules ports, you can set individual man paths using
MANsectPREFIX (where
sect is one of 1-9,
L or N).If your manpages go to language-specific subdirectories, set
the name of the languages to MANLANG. The
value of this variable defaults to "" (i.e.,
English only).Here is an example that puts it all together.
MAN1= foo.1
MAN3= bar.3
MAN4= baz.4
MANLANG= "" ja
MAN3PREFIX= ${PREFIX}/share/foobar
MANCOMPRESSED= yesThis states that six files are installed by this port;
${PREFIX}/man/man1/foo.1.gz
${PREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/share/foobar/man/man3/bar.3.gz
${PREFIX}/share/foobar/man/ja/man3/bar.3.gz
${PREFIX}/man/man4/baz.4.gz
${PREFIX}/man/ja/man4/baz.4.gzPorts that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is
a free clone reported to be able to run many applications in
x11-toolkits/lesstif) to compile. Since
it is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically (for people who are compiling from the port) or
statically (for people who distribute packages).REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.MOTIFLIBThis variable will be set by
bsd.port.mk to be the appropriate reference
to the Motif library. Please patch the source to use this
wherever the Motif library is referenced in the
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its Makefile
or Imakefile, simply substitute
${MOTIFLIB} for
it.If the port uses XmClientLibs
in its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands to
-L/usr/X11R6/lib -lXm or
/usr/X11R6/lib/libXm.a, so there is no need
to add -L or -l in
front.X11 fontsIf your port installs fonts for the X Window system, put them
in
X11BASE/lib/X11/fonts/local.
This directory is new to XFree86 release 3.3.3. If it does not
exist, please create it, and print out a message urging the user
to update their XFree86 to 3.3.3 or newer, or at least add this
directory to the font path in
/etc/XF86Config.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info
to add and delete entries to the dir file. If
your port installs any info documents, please follow this
instructions so your port/package will correctly update the user's
PREFIX/info/dir
file. (Sorry for the length of this section, but is it imperative
to weave all the info files together. If done correctly, it will
produce a beautiful listing, so please bear
with me!First, this is what you (as a porter) need to know&prompt.user; install-info --help
install-info [OPTION]... [INFO-FILE [DIR-FILE]]
Install INFO-FILE in the Info directory file DIR-FILE.
Options:
--delete Delete existing entries in INFO-FILE;
don't insert any new entries.
:
--entry=TEXT Insert TEXT as an Info directory entry.
:
--section=SEC Put this file's entries in section SEC of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11 1995
+++ ./man/vip.texi Tue May 20 01:28:33 1997
@@ -2,6 +2,10 @@
@setfilename ../info/vip
@settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry
+* VIP: (vip). A VI-emulation for Emacs.
+@end direntry
@iftex
@finalout
:The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Tue Apr 15 00:15:28 1997
@@ -184,7 +184,7 @@
# Subdirectories to make recursively. `lisp' is not included
# because the compiled lisp files are part of the distribution
# and you cannot remake them without installing Emacs first.
-SUBDIR = lib-src src
+SUBDIR = lib-src src man
# The makefiles of the directories in $SUBDIR.
SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile
--- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996
+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997
@@ -66,6 +66,7 @@
${srcdir}/gnu1.texi \
${srcdir}/glossary.texi
+all: info
info: $(INFO_TARGETS)
dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19 1996
+++ ./Makefile.in Mon Apr 14 23:38:07 1997
@@ -368,14 +368,8 @@
if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \
then \
(cd ${infodir}; \
- if [ -f dir ]; then \
- if [ ! -f dir.old ]; then mv -f dir dir.old; \
- else mv -f dir dir.bak; fi; \
- fi; \
cd ${srcdir}/info ; \
- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir); \
for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \
(cd $${thisdir}; \
${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \
chmod a+r ${infodir}/$$f); \(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/04/15 06:32:12
@@ -15,9 +15,6 @@
man/man1/emacs.1.gz
man/man1/etags.1.gz
man/man1/ctags.1.gz
-@unexec cp %D/info/dir %D/info/dir.bak
-info/dir
-@unexec cp %D/info/dir.bak %D/info/dir
info/cl
info/cl-1
info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- Makefile 1996/11/19 13:14:40 1.26
+++ Makefile 1997/05/20 10:25:09 1.28
@@ -20,5 +20,11 @@
post-install:
.for file in emacs-19.34 emacsclient etags ctags b2m
strip ${PREFIX}/bin/${file}
.endfor
+ if [ ! -f ${PREFIX}/info/dir ]; then \
+ ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \
+ fi
+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode
+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir
+.endfor
.include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
===================================================================
RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v
retrieving revision 1.15
diff -u -r1.15 PLIST
--- PLIST 1997/03/04 08:04:00 1.15
+++ PLIST 1997/05/20 10:25:12 1.17
@@ -16,7 +14,15 @@
man/man1/etags.1.gz
man/man1/ctags.1.gz
+@unexec install-info --delete %D/info/emacs %D/info/dir
:
+@unexec install-info --delete %D/info/ccmode %D/info/dir
info/cl
info/cl-1
@@ -87,6 +94,18 @@
info/viper-3
info/viper-4
+@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
+@exec install-info %D/info/emacs %D/info/dir
:
+@exec install-info %D/info/ccmode %D/info/dir
libexec/emacs/19.34/i386--freebsd/cvtmail
libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :). Check the dir file before and after each
step.The pkg/ subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.MESSAGEIf you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capability is often useful to display additional installation
steps to be taken after a pkg_add or to display
licensing information.The pkg/MESSAGE file does not need to
be added to pkg/PLIST. Also, it will not get
automatically printed if the user is using the port, not the
package, so you should probably display it from the
post-install target yourself.INSTALL
- If your port needs execute commands when the binary package is
- installed with pkg_add you can do with via the
+ If your port needs to execute commands when the binary package is
+ installed with pkg_add you can do this via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice by
pkg_add. The first time will as
INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be
tested to determine which mode the script is being run in. The
PKG_PREFIX environmental variable will be set to
the package installation directory. See pkg_add1 for additional
information.This script is not run automatically if you install the port
with make install. If you are depending on
- it being run, you will have to explicitly call it on your port's
+ it being run, you will have to explicitly call it from your port's
Makefile.REQIf your port needs to determine if it should install or not,
you can create a pkg/REQ
“requirements” script. It will be invoked
automatically at installation/deinstallation time to determine
whether or not installation/deinstallation should proceed.Changing PLIST based on make variablesSome ports, particularly the p5- ports, need to change their
PLIST depending on what options they are
configured with (or version of perl, in the case of p5- ports). To
make this easy, any instances in the PLIST of
%%OSREL%%, %%PERL_VER%%, and
%%PERL_VERSION%% will be substituted for
appropriately. The value of %%OSREL%% is the
numeric revision of the operating system (e.g.,
2.2.7). %%PERL_VERSION%% is
the full version number of perl (e.g., 5.00502)
and %%PERL_VER%% is the perl version number
minus the patchlevel (e.g., 5.005).If you need to make other substitutions, you can set the
PLIST_SUB variable with a list of
VAR=VALUE
pairs and instances of
%%VAR%%' will be
substituted with VALUE in the
PLIST.For instance, if you have a port that installs many files in
a version-specific subdirectory, you can put something
like
OCTAVE_VERSION= 2.0.13
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION}
in the Makefile and use
%%OCTAVE_VERSION%% wherever the version shows
up in PLIST. That way, when you upgrade the
port, you will not have to change dozens (or in some cases,
hundreds) of lines in the PLIST.This substitution (as well as addition of any man pages) will be done
between the do-install and
post-install targets, by reading from
PLIST and writing to
TMPPLIST (default:
WRKDIR/.PLIST.mktmp). So
if your port builds PLIST on the fly, do so in
or before do-install. Also, if your port
needs to edit the resulting file, do so in
post-install to a file named
TMPPLIST.
+
+
+ Changing the names of files in the
+ pkg subdirectory
+
+ All the filenames in the pkg subdirectory
+ are defined using variables so you can change them in your
+ Makefile if need be. This is especially useful when you
+ are sharing the same pkg subdirectory among
+ several ports or have to write to one of the above files (see
+ writing to places other than
+ WRKDIR for why it is a bad idea to
+ write directly in to the pkg
+ subdirectory.
+
+ Here is a list of variable names and their default
+ values.
+
+
+
+
+
+ Variable
+ Default value
+
+
+
+
+
+ COMMENT
+ ${PKGDIR}/DESCR
+
+
+
+ DESCR
+ ${PKGDIR}/DESCR
+
+
+
+ PLIST
+ ${PKGDIR}/PLIST
+
+
+
+ PKGINSTALL
+ ${PKGDIR}/PKGINSTALL
+
+
+
+ PKGDEINSTALL
+ ${PKGDIR}/PKGDEINSTALL
+
+
+
+ PKGREQ
+ ${PKGDIR}/REQ
+
+
+
+ PKGMESSAGE
+ ${PKGDIR}/MESSAGE
+
+
+
+
+
+ Please change these variables rather than overriding
+ PKG_ARGS. If you change
+ PKG_ARGS, those files will not correctly be
+ installed in /var/db/pkg upon install from a
+ port.
+
-
+
Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
- can do with them vary a lot, depending on the exact wordings of
+ can do with them varies a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a “do not sell for profit” type of
license, set the variable NO_CDROM to a
string describing the reason why. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE to a string describing the
reason why. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a “no commercial use” license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (e.g., if your modified port
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category ports). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.You should check your own port
against this list, but you can also check ports in the PR
database that others have submitted. Submit any comments on
ports you check as described in Bug
Reports and General Commentary. Checking ports in
the PR database will both make it faster for us to commit them,
and prove that you know what you are doing.Strip BinariesDo strip binaries. If the original source already strips the
binaries, fine; otherwise you should add a
post-install rule to to it yourself. Here is an
example;
post-install:
strip ${PREFIX}/bin/xdlUse the file1 command on the installed executable to check
whether the binary is stripped or not. If it does not say
not stripped, it is stripped.INSTALL_* macrosDo use the macros provided in bsd.port.mk
to ensure correct modes and ownership of files in your own
*-install targets. They are:INSTALL_PROGRAM is a command to install
binary executables.INSTALL_SCRIPT is a command to install
executable scripts.INSTALL_DATA is a command to install
sharable data.INSTALL_MAN is a command to install
manpages and other documentation (it doesn't compress
anything).These are basically the install command
with all the appropriate flags. See below for an example on how
to use them.
+
+
+ WRKDIR
+
+ Do not write anything to files outside
+ WRKDIR. WRKDIR is the only
+ place that is guaranteed to be writable during the port build (see
+ compiling ports from CDROM for an
+ example of building ports from a read-only tree). If you need to
+ modigy some file in PKGDIR, do so by redefining a variable, not by
+ writing over it.
+
+
+
+ WRKDIRPREFIX
+
+ Make sure your port honors
+ WRKDIRPREFIX. Most ports don't have to worry
+ about this. In particular, if you are referring to a
+ WRKDIR of another port, note that the correct
+ location is
+ WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such.
+
+ Also, if you are defining WRKDIR yourself,
+ make sure you prepend
+ ${WKRDIRPREFIX}${.CURDIR} in the
+ front.
+ Differentiating operating systems and OS versionsYou may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as general
as possible so that we can back-port code to FreeBSD 1.x systems
and cross-port to other BSD systems such as 4.4BSD from CSRG,
BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file is
already included; if not, add the code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endifto the proper place in the .c file. We
- believe that every system that defines these to symbols has
+ believe that every system that defines these two symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to the
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile
for this method.Once you have sys/param.h
included, you may use:
#if (defined(BSD) && (BSD >= 199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:
#if (defined(BSD) && (BSD >= 199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is
199506 for the 4.4BSD-Lite2 code base. This is
stated for informational purposes only. It should not be used to
- distinguish between version of FreeBSD based only on 4.4-Lite vs.
+ distinguish between versions of FreeBSD based only on 4.4-Lite vs.
versions that have merged in changes from 4.4-Lite2. The
__FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
only affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2
#include <osreldate.h>
# if __FreeBSD_version >= 199504
/* 2.0.5+ release specific code here */
# endif
#endifRelease_FreeBSD_version2.0-RELEASE1194112.1-currents199501, 1995032.0.5-RELEASE1995042.2-current before 2.11995082.1.0-RELEASE1995112.2-current before 2.1.51995122.1.5-RELEASE1996072.2-current before 2.1.61996082.1.6-RELEASE1996122.1.7-RELEASE1996122.2-RELEASE2200002.2.1-RELEASE220000 (no change)2.2-STABLE after 2.2.1-RELEASE220000 (no change)2.2-STABLE after texinfo-3.92210012.2-STABLE after top2210022.2.2-RELEASE2220002.2-STABLE after 2.2.2-RELEASE2220012.2.5-RELEASE2250002.2-STABLE after 2.2.5-RELEASE2250012.2-STABLE after ldconfig -R merge2250022.2.6-RELEASE2260002.2.7-RELEASE2270002.2-STABLE after 2.2.7-RELEASE2270012.2-STABLE after semctl(2) change2270022.2.8-RELEASE2280002.2-STABLE after 2.2.8-RELEASE2280013.0-current before mount(2) change3000003.0-current after mount(2) change3000013.0-current after semctl(2) change3000023.0-current after ioctl arg changes3000033.0-current after ELF conversion3000043.0-RELEASE3000053.0-current after 3.0-RELEASE300006
+
+
+ 3.0-stable after 3/4 branch
+ 300007
+
+
+
+ 3.1-RELEASE
+ 310000
+
+
+
+ 3.1-stable after 3.1-RELEASE
+ 310001
+
+
+
+ 4.0-current after 3/4 branch
+ 400000
+ Note that 2.2-STABLE sometimes identifies itself as
“2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Writing something after
bsd.port.mkDo not write anything after the .include
<bsd.port.mk> line. it usually can be avoided by
including bsd.port.pre.mk somewhere in the
middle of your Makefile and
bsd.port.post.mk at the end.You need to include either the
pre.mk/post.mk pair or
bsd.port.mk only; don't mix these
two.bsd.port.pre.mk only defines a few
variables, which can be used in tests in the
Makefile,
bsd.port.post.mk defines the rest.Here are some important variables defined in
bsd.port.pre.mk (this is not the complete
list, please read bsd.port.mk for the
complete list).VariableDescriptionARCHThe architecture as returned by uname
-m (e.g., i386)OPSYSThe operating system type, as returned by
uname -s (e.g.,
FreeBSD)OSRELThe release version of the operating system (e.g.,
2.1.5 or
2.2.7)OSVERSIONThe numeric version of the operating system, same as
__FreeBSD_version.PORTOBJFORMATThe object format of the system
(aout or elfLOCALBASEThe base of the “local” tree (e.g.,
/usr/local/)X11BASEThe base of the “X11” tree (e.g.,
/usr/X11R6)PREFIXWhere the port installs itself (see more on
PREFIX).If you have to define the variables
USE_IMAKE, USE_X_PREFIX,
or MASTERDIR, do so before including
bsd.port.pre.mk.Here are some examples of things you can write after
bsd.port.pre.mk;
# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif
# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif
# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endifInstall additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
PREFIX/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means PKGNAME minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole PKGNAME.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)Also you can use the pkg/MESSAGE file to
display messages upon installation. See the using
pkg/MESSAGE section for
details.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
Makefile), set DIST_SUBDIR to the name of the
port (PKGNAME without the
version part should work fine). This will change DISTDIR from the default
/usr/ports/distfiles to
/usr/ports/distfiles/DIST_SUBDIR,
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting DISTDIR explicitly in your
Makefile will not accomplish this, so please use DIST_SUBDIR.)This does not affect the MASTER_SITES you define in your
Makefile.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
NO_PACKAGE is
set.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. If you had to edit
configure.in and run
autoconf to regenerate
configure, do not take the diffs of
configure (it often grows to a few thousand
lines!); define USE_AUTOCONF=yes and take the
diffsof configure.in.Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resulting diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to PREFIX. (The value of this
variable will be set to LOCALBASE (default
/usr/local), unless USE_X_PREFIX or USE_IMAKE is set, in which case it
will be X11BASE (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read PREFIX, as this
variable is automatically passed down to every stage of the
build and install processes.Do not set USE_X_PREFIX unless your port
truly require it (i.e., it links against X libs or it needs to
reference files in X11BASE).The variable PREFIX
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles.Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\"
or
-DPAGER=\"${LOCALBASE}/bin/less\"
if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of PREFIX. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
- details, the rule governing /usr pretty
- much applies to /usr/local too. The
+ details, the rules governing /usr pretty
+ much apply to /usr/local too. The
exception are ports dealing with USENET “news”. They may use
PREFIX/news as a destination for
their files.Cleaning up empty directoriesDo make your ports clean up after themselves when they are
deinstalled. This is usually accomplished by adding
@dirrm lines for all directories that are
specifically created by the port. You need to delete
subdirectories before you can delete parent directories.
:
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
:
@dirrm lib/X11/oneko/pixmals
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/onekoHowever, sometimes @dirrm will give you
errors because other ports also share the same subdirectory. You
can call rmdir from @unexec
to remove only empty directories without warning.
@unexec rmdir %D/share/doc/gimp 2>/dev/null || trueThis will neither print any error messages nor cause
pkg_delete to exit abnormally even if
PREFIX/share/doc/gimp is
not empty due to other ports installing some files in there.UIDsIf your port requires a certain user to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at net/cvsup-mirror
for an example.If your port must use the same user/group ID number when it is
installed a binarypackage as when it was compiled, then you mus
choose a free UID from 50 to 99 and register it below. Look at
japanese/Wnn for an example.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/shPlease include a notice when you submit a port (or an
upgrade) that reserves a new UID or GID in this range. This allows
us to keep the list of reserved IDs up to date.Do things rationallyThe Makefile should do things simply and
reasonably. If you can make it a couple of lines shorter or more
readable, then do so. Examples include using a make
.if construct instead of a shell
if construct, not redefining
do-extract if you can redefine
EXTRACT* instead, and using
GNU_CONFIGURE instead of
CONFIGURE_ARGS +=
--prefix=${PREFIX}.Respect CFLAGSThe port should respect the CFLAGS
variable. If it doesn't, please add NO_PACKAGE=ignores
cflags to the Makefile.Configuration filesIf your port requires some configuration files in
PREFIX/etc, do
not just install them and list them in
pkg/PLIST. That will cause
pkg_delete to delete files carefully edited by
the user and a new installation to wipe them out.Instead, install sample files with a suffix
(filename.sample
will work well) and print out a message pointing out that the
user has to copy and edit the file before the software can be made
to work.PortlintDo check your work with portlint
before you submit or commit it.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code. This
will only make your job that much easier for the next
release.MiscellaneaThe files pkg/DESCR,
pkg/COMMENT, and
pkg/PLIST should each be double-checked. If
you are reviewing a port and feel they can be worded better, do
so.Don't copy more copies of the GNU General Public License into
our system, please.Please be careful to note any legal issues! Don't let us
illegally distribute software!If you are stuck…Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample MakefileHere is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). This format is
designed so that the most important information is easy to
locate. We recommend that you use portlint to check the Makefile.
[the header...just to make it easier for us to identify the ports.]
# New ports collection makefile for: xdvi
[the version required header should updated when upgrading a port.]
# Version required: pl18 [things like "1.5alpha" are fine here too]
[this is the date when the first version of this Makefile was created.
Never change this when doing an update of the port.]
# Date created: 26 May 1995
[this is the person who did the original port to FreeBSD, in particular, the
person who wrote the first version of this Makefile. Remember, this should
not be changed when upgrading the port later.]
# Whom: Satoshi Asami <asami@FreeBSD.ORG>
#
# $Id$
[ ^^^^ This will be automatically replaced with RCS ID string by CVS
when it is committed to our repository.]
#
[section to describe the port itself and the master site - DISTNAME
is always first, followed by PKGNAME (if necessary), CATEGORIES,
and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be specified too.]
DISTNAME= xdvi
PKGNAME= xdvi-pl18
CATEGORIES= print
[do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros]
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz" form]
EXTRACT_SUFX= .tar.Z
[section for distributed patches -- can be empty]
PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/
PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz
[maintainer; *mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug reports - this
person should be the porter or someone who can forward questions to the
original porter reasonably promptly. If you really do not want to have
your address here, set it to "ports@FreeBSD.ORG".]
MAINTAINER= asami@FreeBSD.ORG
[dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript
LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm
[this section is for other standard bsd.port.mk variables that do not
belong to any of the above]
[If it asks questions during configure, build, install...]
IS_INTERACTIVE= yes
[If it extracts to a directory other than ${DISTNAME}...]
WRKSRC= ${WRKDIR}/xdvi-new
[If the distributed patches were not made relative to ${WRKSRC}, you
may need to tweak this]
PATCH_DIST_STRIP= -p1
[If it requires a "configure" script generated by GNU autoconf to be run]
GNU_CONFIGURE= yes
[If it requires GNU make, not /usr/bin/make, to build...]
USE_GMAKE= yes
[If it is an X application and requires "xmkmf -a" to be run...]
USE_IMAKE= yes
[et cetera.]
[non-standard variables to be used in the rules below]
MY_FAVORITE_RESPONSE= "yeah, right"
[then the special rules, in the order they are called]
pre-fetch:
i go fetch something, yeah
post-patch:
i need to do something after patch, great
pre-install:
and then some more stuff before installing, wow
[and then the epilogue]
.include <bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like language-name-compiled.specifics-version.numbers.If your DISTNAME
doesn't look like that, set PKGNAME to something in that
format.FreeBSD strives to support the native language of its
users. The language- part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
ja for Japanese, ru for Russian, vi for Vietnamese,
zh for Chinese, ko for Korean and de for German.The name part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a port of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the capital letters are
important to the name (for example, with one-letter names
like R or V) you may use capital letters at your discretion.
There is a tradition of naming Perl 5 modules by prepending
p5- and converting the double-colon separator to a hyphen;
for example, the Data::Dumper module becomes
p5-Data-Dumper. If the software in question has numbers,
hyphens, or underscores in its name, you may include them as
well (like kinput2).If the port can be built with different hardcoded
defaults (usually part of the directory name in a
family of ports), the
-compiled.specifics part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string pl (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a DISTNAME into a suitable PKGNAME:Distribution NamePackage NameReasonmule-2.2.2.mule-2.2.2No changes requiredXFree86-3.1.2XFree86-3.1.2No changes requiredEmiClock-1.0.2emiclock-1.0.2No uppercase names for single programsgmod1.4gmod-1.4Need a hyphen before version numbersxmris.4.0.2xmris-4.0.2Need a hyphen before version numbersrdist-1.3alphardist-1.3aNo strings like alpha
allowedes-0.9-beta1es-0.9b1No strings like beta
allowedv3.3beta021.srctiff-3.3What the heck was that anyway?tvtwmtvtwm-pl11Version string always requiredpiewmpiewm-1.0Version string always requiredxvgr-2.10pl1xvgr-2.10.1pl allowed only when no
major/minor version numbersgawk-2.15.6ja-gawk-2.15.6Japanese language versionpsutils-1.13psutils-letter-1.13Papersize hardcoded at package build timepkfontspkfonts300-1.0Package for 300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to 1.0 (like the piewm example above). Otherwise, ask the
original author or use the date string (yy.mm.dd) as the
version.CategoriesAs you already know, ports are classified in several
categories. But for this to wor, it is important that porters and
users understand what each category and how we deicde what to put in
each category.Current list of categoriesFirst, this is the current list of port categories. Those
marked with an asterisk (*) are
virtual categories—those that do not
have a corresponding subdirectory in the ports tree.For non-virtual categories, you will find a one-line
description in the pkg/COMMENT file in that
subdirectory (e.g.,
archivers/pkg/COMMENT).CategoryDescription
+
+ afterstep*
+ Ports to support AfterStep window manager
+
+
archiversArchiving tools.astroAstronomical ports.audioSound support.benchmarksBenchmarking utilities.biologyBiology-related software.cadComputer aided design tools.chineseChinese language support.commsCommunication software. Mostly software to talk to
your serial port.convertersCharacter code converters.databasesDatabases.deskutilsThings that used to be on the desktop before
computers were invented.develDevelopment utilities. Do not put libraries here just
because they are libraries—unless they truly don't
belong to anywhere else, they shouldn't be in this
category.editorsGeneral editors. Specialized editors go in the
section for those tools (e.g., a mathematical-formula
editor will go in math).elispEmacs-lisp ports.emulatorsEmulators for other operating systems. Terminal
emulators do not belong
here—X-based ones should go to
x11 and text-based ones to either
comms or misc,
depending on the exact functionality.gamesGames.germanGerman language support.graphicsGraphics utilities.japaneseJapanese language support.kde*Ports that form the K Desktop Environment
(kde).koreanKorean language support.langProgramming languages.mailMail software.mathNumerical computation software and other utilities
for mathematics.mboneMBone applications.miscMiscellaneous utilities—basically things that
doesn't belong to anywhere else. This is the only category
that should not appear with any other non-virtual
category. If you have misc with
something else in your CATEGORIES line,
that means you can safely delete misc
and just put the port in that other subdirectory!netMiscellaneous networking software.newsUSENET news software.offix*Ports from the OffiX suite.
- perl5*
- Ports that require perl version 5 to run.
+ palm
+ Software support for the 3Com Palm(tm) series.
-
+
- pilot*
- Software to use with the 3Com PalmPilot.
+ perl5*
+ Ports that require perl version 5 to run.
- plan9
+ plan9*Various programs from Plan9.printPrinting software. Desktop publishing tools
(previewers, etc.) belong here too.python*Software written in python.russianRussian language support.securitySecurity utilities.shellsCommand line shells.sysutilsSystem utilities.tcl75*Ports that use tcl version 7.5 to run.tcl76*Ports that use tcl version 7.6 to run.tcl80*Ports that use tcl version 8.0 to run.tcl81*Ports that use tcl version 8.1 to run.textprocText processing utilities. It does not include
desktop publishing tools, which go to print/.tk41*Ports that use tk version 4.1 to run.tk42*Ports that use tk version 4.2 to run.tk80*Ports that use tk version 8.0 to run.tk81*Ports that use tk version 8.1 to run.vietnameseVietnamese language support.
+
+ windowmaker*
+ Ports to support the WindowMaker window
+ manager
+
+
wwwSoftware related to the World Wide Web. HTML language
support belong here too.x11The X window system and friends. This category is
only for software that directly support the window system.
Do not put regular X applications here. If your port is
an X application, define USE_XLIB
(implied by USE_IMAKE) and put it in
appropriate categories. Also, many of them go into other
x11-* categories (see below).x11-clocksX11 clocks.x11-fmX11 file managers.x11-fontsX11 fonts and font utilities.x11-toolkitsX11 toolkits.x11-wmX11 window managers.Choosing the right categoryAs many of the categories overlap, you often have to choose
which of the categories should be the primary category of your
port. There are several rules that govern this usse. Here is the
list of priorities, in decreasing order of precedence.Language specific categories alwasys come first. For
example, if your port installs Japanese X11 fonts, then your
CATEGORIES line would read
japanese x11.Specific categories win over less-specific ones. For
instance, an HTML editor should be listed as www
editors, not the other way around. Also, you don't
need to list net when the port belongs to
either of mail, mbone,
news, security, or
www.x11 is used as a secondary category
only when the primary category is a natural language. In
particular, you should not put x11 in the
category line for X applications.If your port truly does not belong anywhere else, put it
in misc.If you are not sure about the category, please put a comment
to that effect in your send-pr submission so we
can discuss it before import it. (If you are a committer, send a
note &a.ports; so we can discuss it first—too often new
ports are imported to a wrong category only to be moved right
away.)Changes to this document and the ports systemIf you maintain a lot of ports, you should consider following
the &a.ports;. Important changes to
the way ports work will be announced there. You can always
find more detailed information on the latest changes by
looking at
the bsd.port.mk CVS log.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)