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,
+ Spain,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
- Ukraine,
UK,
+ Ukraine,
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/FreeBSDFrance
-
+
+ In case of problems, please contact the hostmaster
+ hostmaster@fr.FreeBSD.ORG for this
+ domain.
+
-
ftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.
+ URL="ftp://ftp.fr.FreeBSD.ORG/pub/FreeBSD">ftp://ftp.fr.FreeBSD.ORG/pub/FreeBSD
-
+
+
+ ftp://ftp2.fr.FreeBSD.ORG/pub/FreeBSD
+
+
+
+
+
+ ftp://ftp3.fr.FreeBSD.ORG/pub/FreeBSD
+
+ 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/FreeBSD
-
-
-
+
+
+ ftp://ftp6.kr.FreeBSD.ORG/pub/FreeBSD
+
+
+
NetherlandsIn 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: 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/CTM
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/development/CTM">ftp://ftp.freebsd.org/pub/FreeBSD/development/CTM
Germany, 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)Canada
- cvsup.ca.FreeBSD.ORG (maintainer james@ican.net)
+ cvsup.ca.FreeBSD.ORG (maintainer dm@glbalserve.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)
-
+
+
+ cvsup2.ru.FreeBSD.ORG (maintainer
+ dv@dv.ru)
+ 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)Ukrainecvsup2.ua.FreeBSD.ORG (maintainer freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer joe@pavilion.net)USA
- cvsup.FreeBSD.ORG (maintainer skynyrd@opus.cts.cwu.edu)
+ cvsup1.FreeBSD.ORG (maintainer
+ skynyrd@opus.cts.cwu.edu),
+ Washington state
- cvsup2.FreeBSD.ORG (maintainer jdp@FreeBSD.ORG)
+ cvsup2.FreeBSD.ORG (maintainer
+ jdp@FreeBSD.ORG), California
- cvsup3.FreeBSD.ORG (maintainer wollman@FreeBSD.ORG)
+ cvsup3.FreeBSD.ORG (maintainer
+ wollman@FreeBSD.ORG),
+ Massachusetts
- cvsup4.FreeBSD.ORG (maintainer shmit@rcn.com)
+ cvsup4.FreeBSD.ORG (maintainer
+ shmit@rcn.com), Virginia
+
+
+ cvsup5.FreeBSD.ORG (maintainer
+ cvsup@adsu.bellsouth.com),
+ Georgia
+ 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;Sweden
-
+
+ The path to the files are:
+ /afs/stacken.kth.se/ftp/pub/FreeBSD
+
stacken.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/newsgroups.ent b/en/handbook/newsgroups.ent
new file mode 100644
index 0000000000..0c1a8b9821
--- /dev/null
+++ b/en/handbook/newsgroups.ent
@@ -0,0 +1,10 @@
+
+
+comp.unix.bsd.freebsd.misc
+ newsgroup">
+
diff --git a/en/handbook/ports/chapter.sgml b/en/handbook/ports/chapter.sgml
index 2712be81df..35e532e05b 100644
--- a/en/handbook/ports/chapter.sgml
+++ b/en/handbook/ports/chapter.sgml
@@ -1,4672 +1,4674 @@
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 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= /tmpSubstitute /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/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/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.<filename>Makefile</filename>The 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 <filename>files</filename> 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 <filename>patches</filename> directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The <filename>pkg</filename> 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
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/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 <filename>Makefile</filename>The 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.<filename>COMMENT</filename>This 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.<filename>DESCR</filename>This 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
+ It is recommended that you sign your 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.edu<filename>PLIST</filename>This 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 <command>portlint</command>Please 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/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.
+ 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 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 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/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 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.<makevar>DISTNAME</makevar>You 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.<makevar>PKGNAME</makevar>If 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.<makevar>CATEGORIES</makevar>When 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!<makevar>MASTER_SITES</makevar>Record 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.<makevar>PATCHFILES</makevar>If 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 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.<makevar>MAINTAINER</makevar>Set 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.<makevar>LIB_DEPENDS</makevar>This 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.<makevar>RUN_DEPENDS</makevar>This 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.<makevar>BUILD_DEPENDS</makevar>This 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_TARGET<makevar>FETCH_DEPENDS</makevar>This 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.<makevar>DEPENDS</makevar>If 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
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.<command>ldconfig</command>If 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 shortly after 3.0-release,
+ 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
+ system can run as both ELF and a.out, and we wish to unofficially
+ support the 2.2 as long as possible. 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
+ The move-aout-libs target in the 3.0-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.<makevar>PORTOBJFORMAT</makevar>bsd.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
+ aout in 2.2-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.<makevar>LIB_DEPENDS</makevar>All 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.<filename>PLIST</filename>PLIST 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.<literal>ldconfig</literal>The 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.<makevar>MASTERDIR</makevar>If 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).<makevar>REQUIRES_MOTIF</makevar>If 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.<makevar>MOTIFLIB</makevar>This 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 <filename>pkg/</filename> subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.<filename>MESSAGE</filename>If 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.<filename>INSTALL</filename>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 from your port's
Makefile.<filename>REQ</filename>If 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 <filename>PLIST</filename> 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
<filename>pkg</filename> subdirectoryAll 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.VariableDefault valueCOMMENT${PKGDIR}/DESCRDESCR${PKGDIR}/DESCRPLIST${PKGDIR}/PLISTPKGINSTALL${PKGDIR}/PKGINSTALLPKGDEINSTALL${PKGDIR}/PKGDEINSTALLPKGREQ${PKGDIR}/REQPKGMESSAGE${PKGDIR}/MESSAGEPlease 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 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
+ ports/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.
-
+
+ Once again, please use
+ diff1 and not shar1 to send updates to ports.<anchor id="porting-dads">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.<makevar>WRKDIR</makevar>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.<makevar>WRKDIRPREFIX</makevar>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 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 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-RELEASE119411
- 2.1-currents
+ 2.1-CURRENTs199501, 1995032.0.5-RELEASE199504
- 2.2-current before 2.1
+ 2.2-CURRENT before 2.11995082.1.0-RELEASE199511
- 2.2-current before 2.1.5
+ 2.2-CURRENT before 2.1.51995122.1.5-RELEASE199607
- 2.2-current before 2.1.6
+ 2.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-RELEASE228001
- 3.0-current before mount(2) change
+ 3.0-CURRENT before mount(2) change300000
- 3.0-current after mount(2) change
+ 3.0-CURRENT after mount(2) change300001
- 3.0-current after semctl(2) change
+ 3.0-CURRENT after semctl(2) change300002
- 3.0-current after ioctl arg changes
+ 3.0-CURRENT after ioctl arg changes300003
- 3.0-current after ELF conversion
+ 3.0-CURRENT after ELF conversion3000043.0-RELEASE300005
- 3.0-current after 3.0-RELEASE
+ 3.0-CURRENT after 3.0-RELEASE300006
- 3.0-stable after 3/4 branch
+ 3.0-STABLE after 3/4 branch3000073.1-RELEASE310000
- 3.1-stable after 3.1-RELEASE
+ 3.1-STABLE after 3.1-RELEASE310001
- 4.0-current after 3/4 branch
+ 4.0-CURRENT after 3/4 branch400000Note 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
+ you don't have to worry about old -CURRENTs; 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
<filename>bsd.port.mk</filename>Do 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).<makevar>DIST_SUBDIR</makevar>Do 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.<makevar>PREFIX</makevar>Do 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 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 <makevar>CFLAGS</makevar>The 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 <filename>Makefile</filename>Here 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).CategoryDescriptionafterstep*Ports to support AfterStep window managerarchiversArchiving 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.palmSoftware support for the 3Com Palm(tm) series.perl5*Ports that require perl version 5 to run.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
managerwwwSoftware 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/staff/chapter.sgml b/en/handbook/staff/chapter.sgml
index 85ff0bc7b4..9f530dabbb 100644
--- a/en/handbook/staff/chapter.sgml
+++ b/en/handbook/staff/chapter.sgml
@@ -1,838 +1,842 @@
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.shige;
+
+
&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.guido;
+
+
&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.comGallery 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;
+ &a.imp;>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 ad9ec398bc..6d64db5434 100644
--- a/en_US.ISO8859-1/articles/contributing/article.sgml
+++ b/en_US.ISO8859-1/articles/contributing/article.sgml
@@ -1,2954 +1,2558 @@
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;
+ Coordinator: &a.eivind;
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;
- Implement Int13 vm86 disk driver. Coordinator:
- &a.hackers;
+ New bus architecture. Coordinator: &a.newbus;
+
+
+
+ Port existing ISA drivers to new
+ architecture.
+
+
+
+ Move all interrupt-management code to appropriate
+ parts of the bus drivers.
+
+
+
+ Port PCI subsystem to new architecture. Coordinator:
+ &a.dfr;
+
+
+
+ Figure out the right way to handle removable devices
+ and then use that as a substrate on which PC-Card and
+ CardBus support can be implemented.
+
+
+
+ Resolve the probe/attach priority issue once and for
+ all.
+
+
+
+ Move any remaining buses over to the new
+ architecture.
+
+ 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).
-
-
-
-
-
-
+
+
+ Add more pro-active security infrastructure. Overall
+ coordination: &a.security;
+
+
+
+ Build something like Tripwire(TM) into the kernel,
+ with a remote and local part. There are a number of
+ cryptographic issues to getting this right; contact the
+ coordinator for details. Coordinator: &a.eivind;
+
+
+
+ Make the entire kernel use
+ suser() instead of comparing to 0. It
+ is presently using about half of each. Coordinator:
+ &a.eivind;
+
+
+
+ Split securelevels into different parts, to allow an
+ administrator to throw away those privileges he can throw
+ away. Setting the overall securelevel needs to have the
+ same effect as now, obviously. Coordinator:
+ &a.eivind;
+
+
+
+ Make it possible to upload a list of “allowed
+ program” to BPF, and then block BPF from accepting
+ other programs. This would allow BPF to be used e.g. for
+ DHCP, without allowing an attacker to start snooping the
+ local network.
+
+
+
+ Update the security checker script. We should at
+ least grab all the checks from the other BSD derivatives,
+ and add checks that a system with securelevel increased
+ also have reasonable flags on the relevant parts.
+ Coordinator: &a.eivind;
+
+
+
+ Add authorization infrastructure to the kernel, to
+ allow different authorization policies. Part of this
+ could be done by modifying suser().
+ Coordinatory: &a.eivind;
+
+
+
+ Add code to teh NFS layer so that you cannot
+ chdir("..") out of an NFS partition.
+ E.g., /usr is a UFS partition with
+ /usr/src NFS exported. Now it is
+ possible to use the NFS filehandle for
+ /usr/src to get access to
+ /usr.
+
+
+
+
+
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.com
-
-
-
- MCA support? This should be finalized one way or the
- other.
-
-
- Full LKM based driver support/Configuration Manager.
-
+ Full KLD 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,
+ keeps only the KLDs 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
+ The first N items are from Terry Lambert
terry@lambert.org
-
-
- Ability 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
+ Read the freebsd-questions mailing list and &ng.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.<anchor id="donations">Donating funds
- While the FreeBSD Project is not a 501(C3) (non-profit)
+ While the FreeBSD Project is not a 501(c)(3) (charitable)
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.BuffNETPacific
SolutionsHardware 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!
+ ATM switch for debugging the diskless code.
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.
-
+
+
+ Core Team Alumnus
+
+ The following people were members of the FreeBSD core team
+ during the period indicated. We thank them for their past efforts in
+ the service of the FreeBSD project.
+
+ In rough chronological order:
+
+
+
+ Guido van Rooij (1995 - 1999)
+
+
+
+ John Dyson (1993 - 1998)
+
+
+
+ Nate Williams (1992 - 1996)
+
+
+
+ Rod Grimes (1992 - 1995)
+
+
+
+ Andreas Schulz (1992 - 1995)
+
+
+
+ Geoff Rehmet (1993 - 1995)
+
+
+
+ Paul Richards (1992 - 1995)
+
+
+
+ Scott Mace (1993 - 1994)
+
+
+
+ Andrew Moore (1993 - 1994)
+
+
+
+ Christoph Robitschko (1993 - 1994)
+
+
+
+ J. T. Conklin (1992 - 1993)
+
+
+
+
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.jp
-
-
-
- Ada T Lim ada@bsd.org
-
-
-
- Adam Glass glass@postgres.berkeley.edu
-
-
-
- Adam McDougall mcdouga9@egr.msu.edu
-
-
-
- Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu
-
-
-
- Akito Fujita fujita@zoo.ncl.omron.co.jp
-
-
-
- Alain Kalker A.C.P.M.Kalker@student.utwente.nl
-
-
-
- Alan Cox alc@cs.rice.edu
-
-
-
- Amancio Hasty ahasty@freebsd.org
-
-
-
- Andreas Kohout shanee@rabbit.augusta.de
-
-
-
- Andreas Lohr andreas@marvin.RoBIN.de
-
-
-
- Andrew Gallatin gallatin@cs.duke.edu
-
-
-
- Andrew Gordon andrew.gordon@net-tel.co.uk
-
-
-
- Andrew Herbert andrew@werple.apana.org.au
-
-
-
- Andrew McRae amcrae@cisco.com
-
-
-
- Andrew Moore alm@FreeBSD.org
-
-
-
- Andrew Stevenson andrew@ugh.net.au
-
-
-
- Andrew V. Stesin stesin@elvisti.kiev.ua
-
-
-
- Andrey Zakhvatov andy@icc.surw.chel.su
-
-
-
- Andy Whitcroft andy@sarc.city.ac.uk
-
-
-
- Angelo Turetta ATuretta@stylo.it
-
-
-
- Anthony C. Chavez magus@xmission.com
-
-
-
- Anthony Yee-Hang Chan yeehang@netcom.com
-
-
-
- Anton Berezin tobez@plab.ku.dk
-
-
-
- Ari Suutari ari@suutari.iki.fi
-
-
-
- Ben Hutchinson benhutch@xfiles.org.uk
-
-
-
- Bernd Rosauer br@schiele-ct.de
-
-
- Bill Kish kish@osf.org
-
+ ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp
+ AMAGAI Yoshiji amagai@nue.org
+ Aaron Bornstein aaronb@j51.com
+ Aaron Smith aaron@tau.veritas.com
+ Achim Patzner ap@noses.com
+ Ada T Lim ada@bsd.org
+ Adam Baran badam@mw.mil.pl
+ Adam Glass glass@postgres.berkeley.edu
+ Adam McDougall mcdouga9@egr.msu.edu
+ Adrian Colley aecolley@ois.ie
+ Adrian Hall adrian@ibmpcug.co.uk
+ Adrian Mariano adrian@cam.cornell.edu
+ Adrian Steinmann ast@marabu.ch
+ Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu
+ Ajit Thyagarajan
+ Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp
+ Akira SAWADA
+ Akira Watanabe akira@myaw.ei.meisei-u.ac.jp
+ Akito Fujita fujita@zoo.ncl.omron.co.jp
+ Alain Kalker A.C.P.M.Kalker@student.utwente.nl
+ Alan Bawden alan@curry.epilogue.com
+ Alan Cox alc@cs.rice.edu
+ Alec Wolman wolman@cs.washington.edu
+ Aled Morris aledm@routers.co.uk
+ Alex garbanzo@hooked.net
+ Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw
+ Alex G. Bulushev bag@demos.su
+ Alex Le Heux alexlh@funk.org
+ Alexander B. Povolotsky tarkhil@mgt.msk.ru
+ Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE
+ Alexandre Snarskii snar@paranoia.ru
+ Alistair G. Crooks agc@uts.amdahl.com
+ Allan Saddi asaddi@philosophysw.com
+ Allen Campbell allenc@verinet.com
+ Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp
+ Amancio Hasty hasty@star-gate.com
+ Amir Farah amir@comtrol.com
+ Amy Baron amee@beer.org
+ Anatoly A. Orehovsky tolik@mpeks.tomsk.su
+ Anatoly Vorobey mellon@pobox.com
+ Anders Nordby nickerne@nome.no
+ Anders Thulin Anders.X.Thulin@telia.se
+ Andras Olah olah@cs.utwente.nl
+ Andre Albsmeier Andre.Albsmeier@mchp.siemens.de
+ Andre Oppermann andre@pipeline.ch
+ Andreas Haakh ah@alman.robin.de
+ Andreas Kohout shanee@rabbit.augusta.de
+ Andreas Lohr andreas@marvin.RoBIN.de
+ Andreas Schulz
+ Andreas Wetzel mickey@deadline.snafu.de
+ Andreas Wrede andreas@planix.com
+ Andres Vega Garcia
+ Andrew Atrens atreand@statcan.ca
+ Andrew Gillham gillham@andrews.edu
+ Andrew Gordon andrew.gordon@net-tel.co.uk
+ Andrew Herbert andrew@werple.apana.org.au
+ Andrew J. Korty ajk@purdue.edu
+ Andrew L. Moore alm@mclink.com
+ Andrew McRae amcrae@cisco.com
+ Andrew Stevenson andrew@ugh.net.au
+ Andrew Timonin tim@pool1.convey.ru
+ Andrew V. Stesin stesin@elvisti.kiev.ua
+ Andrew Webster awebster@dataradio.com
+ Andrey Zakhvatov andy@icc.surw.chel.su
+ Andy Farkas andyf@speednet.com.au
+ Andy Valencia ajv@csd.mot.com
+ Andy Whitcroft andy@sarc.city.ac.uk
+ Angelo Turetta ATuretta@stylo.it
+ Anthony C. Chavez magus@xmission.com
+ Anthony Yee-Hang Chan yeehang@netcom.com
+ Anton Berezin tobez@plab.ku.dk
+ Antti Kaipila anttik@iki.fi
+ Are Bryne are.bryne@communique.no
+ Ari Suutari ari@suutari.iki.fi
+ Arjan de Vet devet@IAEhv.nl
+ Arne Henrik Juul arnej@Lise.Unit.NO
+ Assar Westerlund assar@sics.se
+ Atsushi Furuta furuta@sra.co.jp
+ Atsushi Murai amurai@spec.co.jp
+ Bakul Shah bvs@bitblocks.com
+ Barry Bierbauch pivrnec@vszbr.cz
+ Barry Lustig barry@ictv.com
+ Ben Hutchinson benhutch@xfiles.org.uk
+ Ben Jackson
+ Ben Smithurst ben@scientia.demon.co.uk
+ Ben Walter bwalter@itachi.swcp.com
+ Benjamin Lewis bhlewis@gte.net
+ Bernd Rosauer br@schiele-ct.de
+ Bill Kish kish@osf.org
+ Bill Trost trost@cloud.rain.com
+ Blaz Zupan blaz@amis.net
+ Bob Van Valzah Bob@whitebarn.com
+ Bob Willcox bob@luke.pmr.com
+ Boris Staeblow balu@dva.in-berlin.de
+ Boyd R. Faulkner faulkner@asgard.bga.com
+ Brad Karp karp@eecs.harvard.edu
+ Bradley Dunn bradley@dunn.org
+ Brandon Gillespie brandon@roguetrader.com
+ &a.wlloyd
+ Bob Wilcox bob@obiwan.uucp
+ Boyd Faulkner faulkner@mpd.tandem.com
+ Brent J. Nordquist bjn@visi.com
+ Brett Lymn blymn@mulga.awadi.com.AU
+ Brett Taylor brett@peloton.physics.montana.edu
+ Brian Campbell brianc@pobox.com
+ Brian Clapper bmc@willscreek.com
+ Brian Cully shmit@kublai.com
+ Brian F. Feldman green@unixhelp.org
+ Brian Handy handy@lambic.space.lockheed.com
+ Brian Litzinger brian@MediaCity.com
+ Brian McGovern bmcgover@cisco.com
+ Brian Moore ziff@houdini.eecs.umich.edu
+ Brian R. Haug haug@conterra.com
+ Brian Tao taob@risc.org
+ Brion Moss brion@queeg.com
+ Bruce A. Mah bmah@ca.sandia.gov
+ Bruce Albrecht bruce@zuhause.mn.org
+ Bruce Gingery bgingery@gtcs.com
+ Bruce J. Keeler loodvrij@gridpoint.com
+ Bruce Murphy packrat@iinet.net.au
+ Bruce Walter walter@fortean.com
+ Carey Jones mcj@acquiesce.org
+ Carl Fongheiser cmf@netins.net
+ Carl Mascott cmascott@world.std.com
+ Casper casper@acc.am
+ Castor Fu castor@geocast.com
+ Cejka Rudolf cejkar@dcse.fee.vutbr.cz
+ Chain Lee chain@110.net
+ Charles Hannum mycroft@ai.mit.edu
+ Charles Henrich henrich@msu.edu
+ Charles Mott cmott@srv.net
+ Charles Owens owensc@enc.edu
+ Chet Ramey chet@odin.INS.CWRU.Edu
+ Chia-liang Kao clkao@CirX.ORG
+ Chiharu Shibata chi@bd.mbn.or.jp
+ Chip Norkus
+ Choi Jun Ho junker@jazz.snu.ac.kr
+ Chris Csanady cc@tarsier.ca.sandia.gov
+ Chris Dabrowski chris@vader.org
+ Chris Dillon cdillon@wolves.k12.mo.us
+ Chris Piazza cpiazza@home.net
+ Chris Shenton cshenton@angst.it.hq.nasa.gov
+ Chris Stenton jacs@gnome.co.uk
+ Chris Timmons skynyrd@opus.cts.cwu.edu
+ Chris Torek torek@ee.lbl.gov
+ Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at
+ Christian Haury Christian.Haury@sagem.fr
+ Christian Weisgerber naddy@bigeye.rhein-neckar.de
+ Christoph P. Kukulies kuku@FreeBSD.org
+ Christoph Robitschko chmr@edvz.tu-graz.ac.at
+ Christoph Weber-Fahr wefa@callcenter.systemhaus.net
+ Christopher G. Demetriou cgd@postgres.berkeley.edu
+ Christopher T. Johnson cjohnson@neunacht.netgsi.com
+ Chrisy Luke chrisy@flix.net
+ Chuck Hein chein@cisco.com
+ Clive Lin clive@CiRX.ORG
+ Colman Reilly careilly@tcd.ie
+ Conrad Sabatier conrads@neosoft.com
+ Coranth Gryphon gryphon@healer.com
+ Cornelis van der Laan nils@guru.ims.uni-stuttgart.de
+ Cove Schneider cove@brazil.nbn.com
+ Craig Leres leres@ee.lbl.gov
+ Craig Loomis
+ Craig Metz cmetz@inner.net
+ Craig Spannring cts@internetcds.com
+ Craig Struble cstruble@vt.edu
+ Cristian Ferretti cfs@riemann.mat.puc.cl
+ Curt Mayer curt@toad.com
+ Cy Schubert cschuber@uumail.gov.bc.ca
+ DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at
+ Dai Ishijima ishijima@tri.pref.osaka.jp
+ Damian Hamill damian@cablenet.net
+ Dan Cross tenser@spitfire.ecsel.psu.edu
+ Dan Lukes dan@obluda.cz
+ Dan Nelson dnelson@emsphone.com
+ Dan Walters hannibal@cyberstation.net
+ Daniel Baker dbaker@crash.ops.neosoft.com
+ Daniel M. Eischen deischen@iworks.InterWorks.org
+ Daniel O'Connor doconnor@gsoft.com.au
+ Daniel Poirot poirot@aio.jsc.nasa.gov
+ Daniel Rock rock@cs.uni-sb.de
+ Danny Egen
+ Danny J. Zerkel dzerkel@phofarm.com
+ Darren Reed avalon@coombs.anu.edu.au
+ Dave Adkins adkin003@tc.umn.edu
+ Dave Andersen angio@aros.net
+ Dave Blizzard dblizzar@sprynet.com
+ Dave Bodenstab imdave@synet.net
+ Dave Burgess burgess@hrd769.brooks.af.mil
+ Dave Chapeskie dchapes@ddm.on.ca
+ Dave Cornejo dave@dogwood.com
+ Dave Edmondson davided@sco.com
+ Dave Glowacki dglo@ssec.wisc.edu
+ Dave Marquardt marquard@austin.ibm.com
+ Dave Tweten tweten@FreeBSD.org
+ David A. Adkins adkin003@tc.umn.edu
+ David A. Bader dbader@umiacs.umd.edu
+ David Borman dab@bsdi.com
+ David Dawes dawes@XFree86.org
+ David Filo filo@yahoo.com
+ David Holland dholland@eecs.harvard.edu
+ David Holloway daveh@gwythaint.tamis.com
+ David Horwitt dhorwitt@ucsd.edu
+ David Hovemeyer daveho@infocom.com
+ David Jones dej@qpoint.torfree.net
+ David Kelly dkelly@tomcat1.tbe.com
+ David Kulp dkulp@neomorphic.com
+ David L. Nugent davidn@blaze.net.au
+ David Leonard d@scry.dstc.edu.au
+ David Malone dwmalone@maths.tcd.ie
+ David Muir Sharnoff muir@idiom.com
+ David S. Miller davem@jenolan.rutgers.edu
+ David Wolfskill dhw@whistle.com
+ Dean Gaudet dgaudet@arctic.org
+ Dean Huxley dean@fsa.ca
+ Denis Fortin
+ Dennis Glatting dennis.glatting@software-munitions.com
+ Denton Gentry denny1@home.com
+ Derek Inksetter derek@saidev.com
+ Dima Sivachenko dima@Chg.RU
+ Dirk Keunecke dk@panda.rhein-main.de
+ Dirk Nehrling nerle@pdv.de
+ Dmitry Khrustalev dima@xyzzy.machaon.ru
+ Dmitry Kohmanyuk dk@farm.org
+ Dom Mitchell dom@myrddin.demon.co.uk
+ Don Croyle croyle@gelemna.ft-wayne.in.us
+ &a.whiteside;
+ Don Morrison dmorrisn@u.washington.edu
+ Don Yuniskis dgy@rtd.com
+ Donald Maddox dmaddox@conterra.com
+ Doug Barton studded@dal.net
+ Douglas Ambrisko ambrisko@whistle.com
+ Douglas Carmichael dcarmich@mcs.com
+ Douglas Crosher dtc@scrooge.ee.swin.oz.au
+ Drew Derbyshire ahd@kew.com
+ Duncan Barclay dmlb@ragnet.demon.co.uk
+ Dustin Sallings dustin@spy.net
+ Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org
+ Ed Gold vegold01@starbase.spd.louisville.edu
+ Ed Hudson elh@p5.spnet.com
+ Edward Wang edward@edcom.com
+ Edwin Groothus edwin@nwm.wan.philips.com
+ Eiji-usagi-MATSUmoto usagi@clave.gr.jp
+ ELISA Font Project
+ Elmar Bartel bartel@informatik.tu-muenchen.de
+ Eric A. Griff eagriff@global2000.net
+ Eric Blood eblood@cs.unr.edu
+ Eric J. Haug ejh@slustl.slu.edu
+ Eric J. Schwertfeger eric@cybernut.com
+ Eric L. Hernes erich@lodgenet.com
+ Eric P. Scott eps@sirius.com
+ Eric Sprinkle eric@ennovatenetworks.com
+ Erich Stefan Boleyn erich@uruk.org
+ Erik E. Rantapaa rantapaa@math.umn.edu
+ Erik H. Moe ehm@cris.com
+ Ernst Winter ewinter@lobo.muc.de
+ Eugene M. Kim astralblue@usa.net
+ Eugene Radchenko genie@qsar.chem.msu.su
+ Evan Champion evanc@synapse.net
+ Faried Nawaz fn@Hungry.COM
+ Flemming Jacobsen fj@tfs.com
+ Fong-Ching Liaw fong@juniper.net
+ Francis M J Hsieh mjshieh@life.nthu.edu.tw
+ Frank Bartels knarf@camelot.de
+ Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw
+ Frank Durda IV uhclem@nemesis.lonestar.org
+ Frank MacLachlan fpm@n2.net
+ Frank Nobis fn@Radio-do.de
+ Frank Volf volf@oasis.IAEhv.nl
+ Frank ten Wolde franky@pinewood.nl
+ Frank van der Linden frank@fwi.uva.nl
+ Fred Cawthorne fcawth@jjarray.umn.edu
+ Fred Gilham gilham@csl.sri.com
+ Fred Templin templin@erg.sri.com
+ Frederick Earl Gray fgray@rice.edu
+ FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp
+ FUJISHIMA Satsuki k5@respo.or.jp
+ FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp
+ Gabor Kincses gabor@acm.org
+ Gabor Zahemszky zgabor@CoDe.hu
+ Garance A Drosehn gad@eclipse.its.rpi.edu
+ Gareth McCaughan gjm11@dpmms.cam.ac.uk
+ Gary A. Browning gab10@griffcd.amdahl.com
+ Gary Howland gary@hotlava.com
+ Gary J. garyj@rks32.pcs.dec.com
+ Gary Kline kline@thought.org
+ Gaspar Chilingarov nightmar@lemming.acc.am
+ Gea-Suan Lin gsl@tpts4.seed.net.tw
+ Geoff Rehmet csgr@alpha.ru.ac.za
+ Georg Wagner georg.wagner@ubs.com
+ Gerard Roudier groudier@club-internet.fr
+ Gianmarco Giovannelli gmarco@giovannelli.it
+ Gil Kloepfer Jr. gil@limbic.ssdl.com
+ Gilad Rom rom_glsa@ein-hashofet.co.il
+ Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp
+ Giles Lean giles@nemeton.com.au
+ Glen Foster gfoster@gfoster.com
+ Glenn Johnson gljohns@bellsouth.net
+ Godmar Back gback@facility.cs.utah.edu
+ Goran Hammarback goran@astro.uu.se
+ Gord Matzigkeit gord@enci.ucalgary.ca
+ Graham Wheeler gram@cdsec.com
+ Greg A. Woods woods@zeus.leitch.com
+ Greg Ansley gja@ansley.com
+ Greg Troxel gdt@ir.bbn.com
+ Greg Ungerer gerg@stallion.oz.au
+ Gregory Bond gnb@itga.com.au
+ Gregory D. Moncreaff moncrg@bt340707.res.ray.com
+ Guy Harris guy@netapp.com
+ Guy Helmer ghelmer@cs.iastate.edu
+ HAMADA Naoki hamada@astec.co.jp
+ HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp
+ HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp
+ Hannu Savolainen hannu@voxware.pp.fi
+ Hans Huebner hans@artcom.de
+ Hans Petter Bieker zerium@webindex.no
+ Hans Zuidam hans@brandinnovators.com
+ Harlan Stenn Harlan.Stenn@pfcs.com
+ Harold Barker hbarker@dsms.com
+ Havard Eidnes Havard.Eidnes@runit.sintef.no
+ Heikki Suonsivu hsu@cs.hut.fi
+ Heiko W. Rupp
+ Helmut F. Wirth hfwirth@ping.at
+ Henrik Vestergaard Draboel hvd@terry.ping.dk
+ Herb Peyerl hpeyerl@NetBSD.org
+ Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp
+ Hidekazu Kuroki hidekazu@cs.titech.ac.jp
+ Hideki Yamamoto hyama@acm.org
+ Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
+ Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+ Hirayama Issei iss@mail.wbs.ne.jp
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+ Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp
+ Hironori Ikura hikura@kaisei.org
+ Hiroshi Nishikawa nis@pluto.dti.ne.jp
+ Hiroya Tsubakimoto
+ Hiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jp
+ Holger Veit Holger.Veit@gmd.de
+ Holm Tiffe holm@geophysik.tu-freiberg.de
+ Horance Chou horance@freedom.ie.cycu.edu.tw
+ Horihiro Kumagaio kuma@jp.freebsd.org
+ Horikawa Kazuo k-horik@mail.yk.rim.or.jp
+ Hr.Ladavac lada@ws2301.gud.siemens.co.at
+ Hubert Feyrer hubertf@NetBSD.ORG
+ Hugh F. Mahon hugh@nsmdserv.cnd.hp.com
+ Hugh Mahon h_mahon@fc.hp.com
+ Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw
+ IMAI Takeshi take-i@ceres.dti.ne.jp
+ IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp
+ Ian Dowse iedowse@maths.tcd.ie
+ Ian Holland ianh@tortuga.com.au
+ Ian Struble ian@broken.net
+ Ian Vaudrey i.vaudrey@bigfoot.com
+ Igor Khasilev igor@jabber.paco.odessa.ua
+ Igor Roshchin str@giganda.komkon.org
+ Igor Sviridov siac@ua.net
+ Igor Vinokurov igor@zynaps.ru
+ Ikuo Nakagawa ikuo@isl.intec.co.jp
+ Ilya V. Komarov mur@lynx.ru
+ Issei Suzuki issei@jp.FreeBSD.org
+ Itsuro Saito saito@miv.t.u-tokyo.ac.jp
+ J. Bryant jbryant@argus.flash.net
+ J. David Lowe lowe@saturn5.com
+ J. Han hjh@best.com
+ J. Hawk jhawk@MIT.EDU
+ J.T. Conklin jtc@cygnus.com
+ J.T. Jang keith@email.gcn.net.tw
+ Jack jack@zeus.xtalwind.net
+ Jacob Bohn Lorensen jacob@jblhome.ping.mk
+ Jagane D Sundar jagane@netcom.com
+ Jake Hamby jehamby@lightside.com
+ James Clark jjc@jclark.com
+ James D. Stewart jds@c4systm.com
+ James Jegers jimj@miller.cs.uwm.edu
+ James Raynard fhackers@jraynard.demon.co.uk
+ James T. Liu jtliu@phlebas.rockefeller.edu
+ James da Silva jds@cs.umd.edu
+ Jan Conard charly@fachschaften.tu-muenchen.de
+ Jan Koum jkb@FreeBSD.org
+ Janick Taillandier Janick.Taillandier@ratp.fr
+ Janusz Kokot janek@gaja.ipan.lublin.pl
+ Jarle Greipsland jarle@idt.unit.no
+ Jason Garman init@risen.org
+ Jason Thorpe thorpej@NetBSD.org
+ Jason Wright jason@OpenBSD.org
+ Jason Young doogie@forbidden-donut.anet-stl.com
+ Javier Martin Rueda jmrueda@diatel.upm.es
+ Jay Fenlason hack@datacube.com
+ Jaye Mathisen mrcpu@cdsnet.net
+ Jeff Bartig jeffb@doit.wisc.edu
+ Jeff Forys jeff@forys.cranbury.nj.us
+ Jeff Kletsky Jeff@Wagsky.com
+ Jeffrey Evans evans@scnc.k12.mi.us
+ Jeffrey Wheat jeff@cetlink.net
+ Jens Schweikhardt schweikh@ito.uni-stuttgart.de
+ Jeremy Allison jallison@whistle.com
+ Jeremy Chatfield jdc@xinside.com
+ Jeremy Lea reg@shale.csir.co.za
+ Jeremy Prior
+ Jeroen Ruigrok/Asmodai asmodai@wxs.nl
+ Jesse Rosenstock jmr@ugcs.caltech.edu
+ Jian-Da Li jdli@csie.nctu.edu.tw
+ Jim Babb babb@FreeBSD.org
+ Jim Binkley jrb@cs.pdx.edu
+ Jim Carroll jim@carroll.com
+ Jim Flowers jflowers@ezo.net
+ Jim Leppek jleppek@harris.com
+ Jim Lowe james@cs.uwm.edu
+ Jim Mattson jmattson@sonic.net
+ Jim Mercer jim@komodo.reptiles.org
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.com
+ Jimbo Bahooli griffin@blackhole.iceworld.org
+ Jin Guojun jin@george.lbl.gov
+ Joachim Kuebart
+ Joao Carlos Mendes Luis jonny@jonny.eng.br
+ Jochen Pohl jpo.drs@sni.de
+ Joe "Marcus" Clarke marcus@miami.edu
+ Joe Abley jabley@clear.co.nz
+ Joe Jih-Shian Lu jslu@dns.ntu.edu.tw
+ Joe Orthoefer j_orthoefer@tia.net
+ Joe Traister traister@mojozone.org
+ Joel Faedi Joel.Faedi@esial.u-nancy.fr
+ Joel Ray Holveck joelh@gnu.org
+ Joel Sutton sutton@aardvark.apana.org.au
+ Johan Granlund johan@granlund.nu
+ Johan Karlsson k@numeri.campus.luth.se
+ Johan Larsson johan@moon.campus.luth.se
+ Johann Tonsing jtonsing@mikom.csir.co.za
+ Johannes Helander
+ Johannes Stille
+ John Baldwin jobaldwi@vt.edu
+ John Beckett jbeckett@southern.edu
+ John Beukema jbeukema@hk.super.net
+ John Brezak
+ John Capo jc@irbs.com
+ John F. Woods jfw@jfwhome.funhouse.com
+ John Goerzen jgoerzen@alexanderwohl.complete.org
+ John Hay jhay@mikom.csir.co.za
+ John Heidemann johnh@isi.edu
+ John Hood cgull@owl.org
+ John Kohl
+ John Lind john@starfire.mn.org
+ John Mackin john@physiol.su.oz.au
+ John P johnp@lodgenet.com
+ John Perry perry@vishnu.alias.net
+ John Preisler john@vapornet.com
+ John Rochester jr@cs.mun.ca
+ John Sadler john_sadler@alum.mit.edu
+ John Saunders john@pacer.nlc.net.au
+ John W. DeBoskey jwd@unx.sas.com
+ John Wehle john@feith.com
+ John Woods jfw@eddie.mit.edu
+ Jon Morgan morgan@terminus.trailblazer.com
+ Jonathan H N Chin jc254@newton.cam.ac.uk
+ Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca
+ Jorge Goncalves j@bug.fe.up.pt
+ Jorge M. Goncalves ee96199@tom.fe.up.pt
+ Jos Backus jbackus@plex.nl
+ Jose M. Alcaide jose@we.lc.ehu.es
+ Josef Grosch jgrosch@superior.mooseriver.com
+ Josef Karthauser joe@uk.freebsd.org
+ Joseph Stein joes@seaport.net
+ Josh Gilliam josh@quick.net
+ Josh Tiefenbach josh@ican.net
+ Juergen Lock nox@jelal.hb.north.de
+ Juha Inkari inkari@cc.hut.fi
+ Jukka A. Ukkonen jua@iki.fi
+ Julian Assange proff@suburbia.net
+ Julian Coleman j.d.coleman@ncl.ac.uk
+ Julian H. Stacey jhs@freebsd.org
+ Julian Jenkins kaveman@magna.com.au
+ Junichi Satoh junichi@jp.freebsd.org
+ Junji SAKAI sakai@jp.freebsd.org
+ Junya WATANABE junya-w@remus.dti.ne.jp
+ K.Higashino a00303@cc.hc.keio.ac.jp
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+ Kai Vorma vode@snakemail.hut.fi
+ Kaleb S. Keithley kaleb@ics.com
+ Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp
+ Kapil Chowksey kchowksey@hss.hns.com
+ Karl Denninger karl@mcs.com
+ Karl Dietz Karl.Dietz@triplan.com
+ Karl Lehenbauer karl@NeoSoft.com
+ Kato Takenori kato@eclogite.eps.nagoya-u.ac.jp
+ Kauzo Horikawa h-horik@yk.rim.or.jp
+ Kawanobe Koh kawanobe@st.rim.or.jp
+ Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp
+ Kazuo Horikawa horikawa@jp.FreeBSD.org
+ Kees Jan Koster kjk1@ukc.ac.uk
+ Keith Bostic bostic@bostic.com
+ Keith E. Walker
+ Keith Moore
+ Keith Sklower
+ Ken Hornstein
+ Ken Key key@cs.utk.edu
+ Ken Mayer kmayer@freegate.com
+ Kenji Saito marukun@mx2.nisiq.net
+ Kenji Tomita tommyk@da2.so-net.or.jp
+ Kenneth Furge kenneth.furge@us.endress.com
+ Kenneth Monville desmo@bandwidth.org
+ Kenneth R. Westerback krw@tcn.net
+ Kenneth Stailey kstailey@gnu.ai.mit.edu
+ Kent Talarico kent@shipwreck.tsoft.net
+ Kent Vander Velden graphix@iastate.edu
+ Kentaro Inagaki JBD01226@niftyserve.ne.jp
+ Kevin Bracey kbracey@art.acorn.co.uk
+ Kevin Day toasty@dragondata.com
+ Kevin Lahey kml@nas.nasa.gov
+ Kevin Street street@iname.com
+ Kevin Van Maren vanmaren@fast.cs.utah.edu
+ Kiroh HARADA kiroh@kh.rim.or.jp
+ Klaus Klein kleink@layla.inka.de
+ Klaus-J. Wolf Yanestra@t-online.de
+ Koichi Sato copan@ppp.fastnet.or.jp
+ Kostya Lukin lukin@okbmei.msk.su
+ Kouichi Hirabayashi kh@mogami-wire.co.jp
+ Kurt D. Zeilenga Kurt@Boolean.NET
+ Kurt Olsen kurto@tiny.mcs.usu.edu
+ L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu
+ Lars Köller Lars.Koeller@Uni-Bielefeld.DE
+ Larry Altneu larry@ALR.COM
+ Laurence Lopez lopez@mv.mv.com
+ Lee Cremeans lcremean@tidalwave.net
+ Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw
+ Lon Willett lon%softt.uucp@math.utah.edu
+ Louis A. Mamakos louie@TransSys.COM
+ Louis Mamakos loiue@TransSys.com
+ Lucas James Lucas.James@ldjpc.apana.org.au
+ Lyndon Nerenberg lyndon@orthanc.com
+ M.C. Wong
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ MIHIRA Sanpei Yoshiro sanpei@sanpei.org
+ MITA Yoshio mita@jp.FreeBSD.ORG
+ MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp
+ MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp
+ Magnus Enbom dot@tinto.campus.luth.se
+ Mahesh Neelakanta mahesh@gcomm.com
+ Makoto MATSUSHITA matusita@jp.freebsd.org
+ Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp
+ Malte Lance malte.lance@gmx.net
+ Manu Iyengar iyengar@grunthos.pscwa.psca.com
+ Marc Frajola marc@dev.com
+ Marc Ramirez mrami@mramirez.sy.yale.edu
+ Marc Slemko marcs@znep.com
+ Marc van Kempen wmbfmk@urc.tue.nl
+ Marcel Moolenaar marcel@scc.nl
+ Mario Sergio Fujikawa Ferreira lioux@gns.com.br
+ Mark Andrews
+ Mark Cammidge mark@gmtunx.ee.uct.ac.za
+ Mark Diekhans markd@grizzly.com
+ Mark Huizer xaa@stack.nl
+ Mark J. Taylor mtaylor@cybernet.com
+ Mark Krentel krentel@rice.edu
+ Mark Mayo markm@vmunix.com
+ Mark Thompson thompson@tgsoft.com
+ Mark Tinguely tinguely@plains.nodak.edu
+ Mark Treacy
+ Mark Valentine mark@linus.demon.co.uk
+ Martin Birgmeier
+ Martin Ibert mib@ppe.bb-data.de
+ Martin Kammerhofer dada@sbox.tu-graz.ac.at
+ Martin Renters martin@tdc.on.ca
+ Martti Kuparinen erakupa@kk.etx.ericsson.se
+ Masachika ISHIZUKA ishizuka@isis.min.ntt.jp
+ Mas.TAKEMURA
+ Masafumi NAKANE max@wide.ad.jp
+ Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp
+ Masanobu Saitoh msaitoh@spa.is.uec.ac.jp
+ Masanori Kanaoka kana@saijo.mke.mei.co.jp
+ Masanori Kiriake seiken@ncs.co.jp
+ Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp
+ Mats Lofkvist mal@algonet.se
+ Matt Bartley mbartley@lear35.cytex.com
+ Matt Thomas matt@3am-software.com
+ Matt White mwhite+@CMU.EDU
+ Matthew C. Mead mmead@Glock.COM
+ Matthew Cashdollar mattc@rfcnet.com
+ Matthew Flatt mflatt@cs.rice.edu
+ Matthew Fuller fullermd@futuresouth.com
+ Matthew N. Dodd winter@jurai.net
+ Matthew Stein matt@bdd.net
+ Matthias Pfaller leo@dachau.marco.de
+ Matthias Scheler tron@netbsd.org
+ Mattias Gronlund Mattias.Gronlund@sa.erisoft.se
+ Mattias Pantzare pantzer@ludd.luth.se
+ Maurice Castro maurice@planet.serc.rmit.edu.au
+ Max Euston meuston@jmrodgers.com
+ Max Khon fjoe@husky.iclub.nsu.ru
+ Maxim Bolotin max@rsu.ru
+ Micha Class michael_class@hpbbse.bbn.hp.com
+ Michael Butler imb@scgt.oz.au
+ Michael Butschky butsch@computi.erols.com
+ Michael Clay mclay@weareb.org
+ Michael Elbel me@FreeBSD.ORG
+ Michael Galassi nerd@percival.rain.com
+ Michael Hancock michaelh@cet.co.jp
+ Michael Hohmuth hohmuth@inf.tu-dresden.de
+ Michael Perlman canuck@caam.rice.edu
+ Michael Petry petry@netwolf.NetMasters.com
+ Michael Reifenberger root@totum.plaut.de
+ Michael Searle searle@longacre.demon.co.uk
+ Michal Listos mcl@Amnesiac.123.org
+ Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp
+ Miguel Angel Sagreras msagre@cactus.fi.uba.ar
+ Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp
+ Mika Nystrom mika@cs.caltech.edu
+ Mikael Hybsch micke@dynas.se
+ Mikael Karpberg karpen@ocean.campus.luth.se
+ Mike Del repenting@hotmail.com
+ Mike Durian durian@plutotech.com
+ Mike Durkin mdurkin@tsoft.sf-bay.org
+ Mike E. Matsnev mike@azog.cs.msu.su
+ Mike Evans mevans@candle.com
+ Mike Grupenhoff kashmir@umiacs.umd.edu
+ Mike Hibler mike@marker.cs.utah.edu
+ Mike Karels
+ Mike McGaughey mmcg@cs.monash.edu.au
+ Mike Meyer mwm@shiva.the-park.com
+ Mike Mitchell mitchell@ref.tfs.com
+ Mike Murphy mrm@alpharel.com
+ Mike Peck mike@binghamton.edu
+ Mike Spengler mks@msc.edu
+ Mikhail A. Sokolov mishania@demos.su
+ Mikhail Teterin mi@aldan.ziplink.net
+ Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW
+ Mitsuru IWASAKI iwasaki@pc.jaring.my
+ Monte Mitzelfelt monte@gonefishing.org
+ Morgan Davis root@io.cts.com
+ Mostyn Lewis mostyn@mrl.com
+ Motoyuki Kasahara m-kasahr@sra.co.jp
+ Motoyuki Konno motoyuki@snipe.rim.or.jp
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.com
+ N.G.Smith ngs@sesame.hensa.ac.uk
+ NAGAO Tadaaki nagao@cs.titech.ac.jp
+ NAKAJI Hiroyuki nakaji@zeisei.dpri.kyoto-u.ac.jp
+ NAKAMURA Kazushi nkazushi@highway.or.jp
+ NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp
+ NIIMI Satoshi sa2c@and.or.jp
+ NOKUBI Hirotaka h-nokubi@yyy.or.jp
+ Nadav Eiron nadav@barcode.co.il
+ Nanbor Wang nw1@cs.wustl.edu
+ Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp
+ Naoki Hamada nao@tom-yam.or.jp
+ Narvi narvi@haldjas.folklore.ee
+ Nathan Dorfman nathan@rtfm.net
+ Neal Fachan kneel@ishiboo.com
+ Neil Blakey-Milner nbm@rucus.ru.ac.za
+ Niall Smart rotel@indigo.ie
+ Nick Barnes Nick.Barnes@pobox.com
+ Nick Handel nhandel@NeoSoft.com
+ Nick Hilliard nick@foobar.org
+ Nick Sayer nsayer@quack.kfu.com
+ Nick Williams njw@cs.city.ac.uk
+ Nickolay N. Dudorov nnd@itfs.nsk.su
+ Niklas Hallqvist niklas@filippa.appli.se
+ Nisha Talagala nisha@cs.berkeley.edu
+ ZW6T-KND@j.asahi-net.or.jp
+ adrian@virginia.edu
+ alex@elvisti.kiev.ua
+ anto@netscape.net
+ bobson@egg.ics.nitch.ac.jp
+ bovynf@awe.be
+ burg@is.ge.com
+ chris@gnome.co.uk
+ colsen@usa.net
+ coredump@nervosa.com
+ dannyman@arh0300.urh.uiuc.edu
+ davids@SECNET.COM
+ derek@free.org
+ devet@adv.IAEhv.nl
+ djv@bedford.net
+ dvv@sprint.net
+ enami@ba2.so-net.or.jp
+ flash@eru.tubank.msk.su
+ flash@hway.ru
+ fn@pain.csrv.uidaho.edu
+ gclarkii@netport.neosoft.com
+ gordon@sheaky.lonestar.org
+ graaf@iae.nl
+ greg@greg.rim.or.jp
+ grossman@cygnus.com
+ gusw@fub46.zedat.fu-berlin.de
+ hfir@math.rochester.edu
+ hnokubi@yyy.or.jp
+ iaint@css.tuu.utas.edu.au
+ invis@visi.com
+ ishisone@sra.co.jp
+ iverson@lionheart.com
+ jpt@magic.net
+ junker@jazz.snu.ac.kr
+ k-sugyou@ccs.mt.nec.co.jp
+ kenji@reseau.toyonaka.osaka.jp
+ kfurge@worldnet.att.net
+ lh@aus.org
+ lhecking@nmrc.ucc.ie
+ mrgreen@mame.mu.oz.au
+ nakagawa@jp.freebsd.org
+ ohki@gssm.otsuka.tsukuba.ac.jp
+ owaki@st.rim.or.jp
+ pechter@shell.monmouth.com
+ pete@pelican.pelican.com
+ pritc003@maroon.tc.umn.edu
+ risner@stdio.com
+ roman@rpd.univ.kiev.ua
+ root@ns2.redline.ru
+ root@uglabgw.ug.cs.sunysb.edu
+ stephen.ma@jtec.com.au
+ sumii@is.s.u-tokyo.ac.jp
+ takas-su@is.aist-nara.ac.jp
+ tamone@eig.unige.ch
+ tjevans@raleigh.ibm.com
+ tony-o@iij.ad.jp amurai@spec.co.jp
+ torii@tcd.hitachi.co.jp
+ uenami@imasy.or.jp
+ uhlar@netlab.sk
+ vode@hut.fi
+ wlloyd@mpd.ca
+ wlr@furball.wellsfargo.com
+ wmbfmk@urc.tue.nl
+ yamagata@nwgpc.kek.jp
+ ziggy@ryan.org
+ Nobuhiro Yasutomi nobu@psrc.isac.co.jp
+ Nobuyuki Koganemaru kogane@koganemaru.co.jp
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+ Noritaka Ishizumi graphite@jp.FreeBSD.ORG
+ Noriyuki Soda soda@sra.co.jp
+ Olaf Wagner wagner@luthien.in-berlin.de
+ Oleg Sharoiko os@rsu.ru
+ Oliver Breuninger ob@seicom.NET
+ Oliver Friedrichs oliver@secnet.com
+ Oliver Fromme oliver.fromme@heim3.tu-clausthal.de
+ Oliver Laumann net@informatik.uni-bremen.de
+ Oliver Oberdorf oly@world.std.com
+ Olof Johansson offe@ludd.luth.se
+ Osokin Sergey aka oZZ ozz@freebsd.org.ru
+ Pace Willisson pace@blitz.com
+ Paco Rosich rosich@modico.eleinf.uv.es
+ Palle Girgensohn girgen@partitur.se
+ Parag Patel parag@cgt.com
+ Pascal Pederiva pascal@zuo.dec.com
+ Pasvorn Boonmark boonmark@juniper.net
+ Patrick Gardella patrick@cre8tivegroup.com
+ Patrick Hausen
+ Paul Antonov apg@demos.su
+ Paul F. Werkowski
+ Paul Fox pgf@foxharp.boston.ma.us
+ Paul Koch koch@thehub.com.au
+ Paul Kranenburg pk@NetBSD.org
+ Paul Mackerras paulus@cs.anu.edu.au
+ Paul Popelka paulp@uts.amdahl.com
+ Paul S. LaFollette, Jr.
+ Paul Saab paul@mu.org
+ Paul Sandys myj@nyct.net
+ Paul T. Root proot@horton.iaces.com
+ Paul Vixie paul@vix.com
+ Paulo Menezes paulo@isr.uc.pt
+ Paulo Menezes pm@dee.uc.pt
+ Pedro A M Vazquez vazquez@IQM.Unicamp.BR
+ Pedro Giffuni giffunip@asme.org
+ Pete Bentley pete@demon.net
+ Peter Childs pjchilds@imforei.apana.org.au
+ Peter Cornelius pc@inr.fzk.de
+ Peter Haight peterh@prognet.com
+ Peter Jeremy perer.jeremy@alcatel.com.au
+ Peter M. Chen pmchen@eecs.umich.edu
+ Peter Much peter@citylink.dinoex.sub.org
+ Peter Olsson
+ Peter Philipp pjp@bsd-daemon.net
+ Peter Stubbs PETERS@staidan.qld.edu.au
+ Phil Maker pjm@cs.ntu.edu.au
+ Phil Sutherland philsuth@mycroft.dialix.oz.au
+ Phil Taylor phil@zipmail.co.uk
+ Philip Musumeci philip@rmit.edu.au
+ Pierre Y. Dampure pierre.dampure@k2c.co.uk
+ Pius Fischer pius@ienet.com
+ Pomegranate daver@flag.blackened.net
+ Powerdog Industries kevin.ruddy@powerdog.com
+ R. Kym Horsell
+ Rajesh Vaidheeswarran rv@fore.com
+ Ralf Friedl friedl@informatik.uni-kl.de
+ Randal S. Masutani randal@comtest.com
+ Randall Hopper rhh@ct.picker.com
+ Randall W. Dean rwd@osf.org
+ Randy Bush rbush@bainbridge.verio.net
+ Reinier Bezuidenhout rbezuide@mikom.csir.co.za
+ Remy Card Remy.Card@masi.ibp.fr
+ Ricardas Cepas rch@richard.eu.org
+ Richard Henderson richard@atheist.tamu.edu
+ Richard Hwang rhwang@bigpanda.com
+ Richard J Kuhns rjk@watson.grauel.com
+ Richard M. Neswold rneswold@drmemory.fnal.gov
+ Richard Seaman, Jr. dick@tar.com
+ Richard Stallman rms@gnu.ai.mit.edu
+ Richard Straka straka@user1.inficad.com
+ Richard Tobin richard@cogsci.ed.ac.uk
+ Richard Wackerbarth rkw@Dataplex.NET
+ Richard Winkel rich@math.missouri.edu
+ Richard Wiwatowski rjwiwat@adelaide.on.net
+ Rick Macklem rick@snowhite.cis.uoguelph.ca
+ Rick Macklin
+ Rob Austein sra@epilogue.com
+ Rob Mallory rmallory@qualcomm.com
+ Rob Snow rsnow@txdirect.net
+ Robert Crowe bob@speakez.com
+ Robert D. Thrush rd@phoenix.aii.com
+ Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de
+ Robert Sanders rsanders@mindspring.com
+ Robert Sexton robert@kudra.com
+ Robert Shady rls@id.net
+ Robert Swindells swindellsr@genrad.co.uk
+ Robert Watson robert@cyrus.watson.org
+ Robert Withrow witr@rwwa.com
+ Robert Yoder
+ Robin Carey robin@mailgate.dtc.rankxerox.co.uk
+ Roger Hardiman roger@cs.strath.ac.uk
+ Roland Jesse jesse@cs.uni-magdeburg.de
+ Ron Bickers rbickers@intercenter.net
+ Ron Lenk rlenk@widget.xmission.com
+ Ronald Kuehn kuehn@rz.tu-clausthal.de
+ Rudolf Cejka
+ Ruslan Belkin rus@home2.UA.net
+ Ruslan Ermilov ru@ucb.crimea.ua
+ Ruslan Shevchenko rssh@cam.grad.kiev.ua
+ Russell L. Carter rcarter@pinyon.org
+ Russell Vincent rv@groa.uct.ac.za
+ Ryan Younce ryany@pobox.com
+ SANETO Takanori sanewo@strg.sony.co.jp
+ SAWADA Mizuki miz@qb3.so-net.ne.jp
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ SURANYI Peter suranyip@jks.is.tsukuba.ac.jp
+ Sakari Jalovaara sja@tekla.fi
+ Sam Hartman hartmans@mit.edu
+ Samuel Lam skl@ScalableNetwork.com
+ Sander Vesik sander@haldjas.folklore.ee
+ Sandro Sigala ssigala@globalnet.it
+ Sascha Blank blank@fox.uni-trier.de
+ Sascha Wildner swildner@channelz.GUN.de
+ Satoh Junichi junichi@astec.co.jp
+ Satoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+ Scot Elliott scot@poptart.org
+ Scot W. Hetzel hetzels@westbend.net
+ Scott A. Kenney saken@rmta.ml.org
+ Scott Blachowicz scott.blachowicz@seaslug.org
+ Scott Burris scott@pita.cns.ucla.edu
+ Scott Hazen Mueller scott@zorch.sf-bay.org
+ Scott Michel scottm@cs.ucla.edu
+ Scott Reynolds scott@clmqt.marquette.mi.us
+ Sebastian Strollo seb@erix.ericsson.se
+ Seigou TANIMURA tanimura@naklab.dnj.ynu.ac.jp
+ Serge A. Babkin babkin@hq.icb.chel.su
+ Serge V. Vakulenko vak@zebub.msk.su
+ Sergei Chechetkin csl@whale.sunbay.crimea.ua
+ Sergei S. Laskavy laskavy@pc759.cs.msu.su
+ Sergey Gershtein sg@mplik.ru
+ Sergey Potapov sp@alkor.ru
+ Sergey Shkonda serg@bcs.zp.ua
+ Sergey V.Dorokhov svd@kbtelecom.nalnet.ru
+ Sergio Lenzi lenzi@bsi.com.br
+ Shaun Courtney shaun@emma.eng.uct.ac.za
+ Shawn M. Carey smcarey@mailbox.syr.edu
+ Sheldon Hearn axl@iafrica.com
+ Shigio Yamaguchi shigio@wafu.netgate.net
+ Shunsuke Akiyama akiyama@jp.freebsd.org
+ Simon simon@masi.ibp.fr
+ Simon Burge simonb@telstra.com.au
+ Simon J Gerraty sjg@melb.bull.oz.au
+ Simon Marlow simonm@dcs.gla.ac.uk
+ Simon Shapiro shimon@simon-shapiro.org
+ Sin'ichiro MIYATANI siu@phaseone.co.jp
+ Slaven Rezic eserte@cs.tu-berlin.de
+ Soochon Radee slr@mitre.org
+ Soren Dayton csdayton@midway.uchicago.edu
+ Soren Dossing sauber@netcom.com
+ Soren S. Jorvang soren@dt.dk
+ Stefan Bethke stb@hanse.de
+ Stefan Eggers seggers@semyam.dinoco.de
+ Stefan Moeding s.moeding@ndh.net
+ Stefan Petri
+ Stefan `Sec` Zehl sec@42.org
+ Steinar Haug sthaug@nethelp.no
+ Stephane E. Potvin sepotvin@videotron.ca
+ Stephane Legrand stephane@lituus.fr
+ Stephen Clawson sclawson@marker.cs.utah.edu
+ Stephen F. Combs combssf@salem.ge.com
+ Stephen Farrell stephen@farrell.org
+ Stephen Hocking sysseh@devetir.qld.gov.au
+ Stephen J. Roznowski sjr@home.net
+ Stephen McKay syssgm@devetir.qld.gov.au
+ Stephen Melvin melvin@zytek.com
+ Steve Bauer sbauer@rock.sdsmt.edu
+ Steve Deering
+ Steve Gerakines steve2@genesis.tiac.net
+ Steve Gericke steveg@comtrol.com
+ Steve Piette steve@simon.chi.il.US
+ Steve Schwarz schwarz@alpharel.com
+ Steven G. Kargl kargl@troutmask.apl.washington.edu
+ Steven H. Samorodin samorodi@NUXI.com
+ Steven McCanne mccanne@cs.berkeley.edu
+ Steven Plite splite@purdue.edu
+ Steven Wallace
+ Stuart Henderson stuart@internationalschool.co.uk
+ Sue Blake sue@welearn.com.au
+ Sugiura Shiro ssugiura@duo.co.jp
+ Sujal Patel smpatel@wam.umd.edu
+ Sune Stjerneby stjerneby@usa.net
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp
+ Tadashi Kumano kumano@strl.nhk.or.jp
+ Taguchi Takeshi taguchi@tohoku.iij.ad.jp
+ Takahashi Yoshihiro nyan@dd.catv.ne.jp
+ Takahiro Yugawa yugawa@orleans.rim.or.jp
+ Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp
+ Takashi Mega mega@minz.org
+ Takashi Uozu j1594016@ed.kagu.sut.ac.jp
+ Takayuki Ariga a00821@cc.hc.keio.ac.jp
+ Takeru NAIKI naiki@bfd.es.hokudai.ac.jp
+ Takeshi Amaike amaike@iri.co.jp
+ Takeshi MUTOH mutoh@info.nara-k.ac.jp
+ Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp
+ Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp
+ Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp
+ Tatoku Ogaito tacha@tera.fukui-med.ac.jp
+ Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org
+ Ted Buswell tbuswell@mediaone.net
+ Ted Faber faber@isi.edu
+ Ted Lemon
+ Terry Lambert terry@lambert.org
+ Terry Lee terry@uivlsi.csl.uiuc.edu
+ Tetsuya Furukawa tetsuya@secom-sis.co.jp
+ Theo de Raadt deraadt@OpenBSD.org
+ Thomas thomas@mathematik.uni-Bremen.de
+ Thomas D. Dean tomdean@ix.netcom.com
+ Thomas David Rivers rivers@dignus.com
+ Thomas G. McWilliams tgm@netcom.com
+ Thomas Gellekum thomas@ghpc8.ihf.rwth-aachen.de
+ Thomas Graichen graichen@omega.physik.fu-berlin.de
+ Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de
+ Thomas Ptacek
+ Thomas Stromberg tstrombe@rtci.com
+ Thomas Valentino Crimi tcrimi+@andrew.cmu.edu
+ Thomas Wintergerst thomas@lemur.nord.de
+ Þórður Ívarsson totii@est.is
+ Tim Kientzle kientzle@netcom.com
+ Tim Singletary tsingle@sunland.gsfc.nasa.gov
+ Tim Wilkinson tim@sarc.city.ac.uk
+ Timo J. Rinne tri@iki.fi
+ Todd Miller millert@openbsd.org
+ Tom root@majestix.cmr.no
+ Tom tom@sdf.com
+ Tom Gray - DCA dcasba@rain.org
+ Tom Hukins tom@eborcom.com
+ Tom Jobbins tom@tom.tj
+ Tom Pusateri pusateri@juniper.net
+ Tom Rush tarush@mindspring.com
+ Tom Samplonius tom@misery.sdf.com
+ Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp
+ Tony Kimball alk@Think.COM
+ Tony Li tli@jnx.com
+ Tony Lynn wing@cc.nsysu.edu.tw
+ Torbjorn Granlund tege@matematik.su.se
+ Toshihiko ARAI toshi@tenchi.ne.jp
+ Toshihiko SHIMOKAWA toshi@tea.forus.or.jp
+ Toshihiro Kanda candy@kgc.co.jp
+ Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp
+ Trefor S. trefor@flevel.co.uk
+ Trevor Blackwell tlb@viaweb.com
+ URATA Shuichiro s-urata@nmit.tmg.nec.co.jp
+ Ugo Paternostro paterno@dsi.unifi.it
+ Ulf Kieber kieber@sax.de
+ Ulli Linzen ulli@perceval.camelot.de
+ Ustimenko Semen semen@iclub.nsu.ru
+ Uwe Arndt arndt@mailhost.uni-koblenz.de
+ Vadim Chekan vadim@gc.lviv.ua
+ Vadim Kolontsov vadim@tversu.ac.ru
+ Vadim Mikhailov mvp@braz.ru
+ Van Jacobson van@ee.lbl.gov
+ Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru
+ Vasim Valejev vasim@uddias.diaspro.com
+ Vernon J. Schryver vjs@mica.denver.sgi.com
+ Vic Abell abe@cc.purdue.edu
+ Ville Eerola ve@sci.fi
+ Vincent Poy vince@venus.gaianet.net
+ Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de
+ Virgil Champlin champlin@pa.dec.com
+ Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua
+ Vladimir Kushnir kushn@mail.kar.net
+ Vsevolod Lobko seva@alex-ua.com
+ W. Gerald Hicks wghicks@bellsouth.net
+ W. Richard Stevens rstevens@noao.edu
+ Walt Howard howard@ee.utah.edu
+ Warren Toomey wkt@csadfa.cs.adfa.oz.au
+ Wayne Scott wscott@ichips.intel.com
+ Werner Griessl werner@btp1da.phy.uni-bayreuth.de
+ Wes Santee wsantee@wsantee.oz.net
+ Wietse Venema wietse@wzv.win.tue.nl
+ Wilfredo Sanchez wsanchez@apple.com
+ Wiljo Heinen wiljo@freeside.ki.open.de
+ Wilko Bulte wilko@yedi.iaf.nl
+ Willem Jan Withagen wjw@surf.IAE.nl
+ William Jolitz withheld
+ William Liao william@tale.net
+ Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl
+ Wolfgang Helbig helbig@ba-stuttgart.de
+ Wolfgang Solfrank ws@tools.de
+ Wolfgang Stanglmeier wolf@FreeBSD.org
+ Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW
+ Yarema yds@ingress.com
+ Yaroslav Terletsky ts@polynet.lviv.ua
+ Yen-Shuo Su yssu@CCCA.NCTU.edu.tw
+ Ying-Chieh Liao ijliao@csie.NCTU.edu.tw
+ Yixin Jin yjin@rain.cs.ucla.edu
+ Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp
+ Yoshihiko OHTA yohta@bres.tsukuba.ac.jp
+ Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp
+ Yoshikazu Goto gotoh@ae.anritsu.co.jp
+ Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp
+ Yoshishige Arai ryo2@on.rim.or.jp
+ Yuichi MATSUTAKA matutaka@osa.att.ne.jp
+ Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp
+ Yukihiro Nakai nacai@iname.com
+ Yusuke Nawano azuki@azkey.org
+ Yuval Yarom yval@cs.huji.ac.il
+ Yves Fonk yves@cpcoup5.tn.tudelft.nl
+ Yves Fonk yves@dutncp8.tn.tudelft.nl
+ Zach Heilig zach@gaffaneys.com
+ Zahemszhky Gabor zgabor@code.hu
+ Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw
+ arci vega@sophia.inria.fr
+ der Mouse mouse@Collatz.McRCIM.McGill.EDU
+ frf frf@xocolatl.com
+ Ege Rekk aagero@aage.priv.no
-
- Brandon Gillespie brandon@roguetrader.com
-
-
-
- &a.wlloyd;
-
-
-
- Bob Wilcox bob@obiwan.uucp
-
-
-
- Boyd Faulkner faulkner@mpd.tandem.com
-
-
-
- Brent J. Nordquist bjn@visi.com
-
-
-
- Brett Taylor brett@peloton.physics.montana.edu
-
-
-
- Brian Clapper bmc@willscreek.com
-
-
-
- Brian F. Feldman green@unixhelp.org
-
-
-
- Brian Handy handy@lambic.space.lockheed.com
-
-
-
- Brian Tao taob@risc.org
-
-
-
- Brion Moss brion@queeg.com
-
-
-
- Bruce Gingery bgingery@gtcs.com
-
-
-
- Bruce Mah bmah@ca.sandia.gov
-
-
-
- Carey Jones mcj@acquiesce.org
-
-
-
- Carl Fongheiser cmf@netins.net
-
-
-
- Charles Hannum mycroft@ai.mit.edu
-
-
-
- Charles Mott cmott@srv.net
-
-
-
- Chet Ramey chet@odin.INS.CWRU.Edu
-
-
-
- Chia-liang Kao clkao@CirX.ORG
-
-
-
- Chris Dabrowski chris@vader.org
-
-
-
- Chris G. Demetriou cgd@postgres.berkeley.edu
-
-
-
- Chris Shenton cshenton@angst.it.hq.nasa.gov
-
-
-
- Chris Stenton jacs@gnome.co.uk
-
-
-
- Chris Timmons skynyrd@opus.cts.cwu.edu
-
-
-
- Chris Torek torek@ee.lbl.gov
-
-
-
- Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at
-
-
-
- Christian Haury Christian.Haury@sagem.fr
-
-
-
- Christoph Robitschko chmr@edvz.tu-graz.ac.at
-
-
-
- Christopher T. Johnson
- cjohnson@neunacht.netgsi.com
-
-
-
- Choi Jun Ho junker@jazz.snu.ac.kr
-
-
-
- Chuck Hein chein@cisco.com
-
-
-
- Clive Lin clive@CiRX.ORG
-
-
-
- Conrad Sabatier conrads@neosoft.com
-
-
-
- Cornelis van der Laan nils@guru.ims.uni-stuttgart.de
-
-
-
- Craig Struble cstruble@vt.edu
-
-
-
- Cristian Ferretti cfs@riemann.mat.puc.cl
-
-
-
- Curt Mayer curt@toad.com
-
-
-
- Dai Ishijima ishijima@tri.pref.osaka.jp
-
-
-
- Dan Cross tenser@spitfire.ecsel.psu.edu
-
-
-
- Daniel Baker dbaker@crash.ops.neosoft.com
-
-
-
- Daniel M. Eischen deischen@iworks.InterWorks.org
-
-
-
- Daniel O'Connor doconnor@gsoft.com.au
-
-
-
- Danny J. Zerkel dzerkel@feephi.phofarm.com
-
-
-
- Dave Bodenstab imdave@synet.net
-
-
-
- Dave Burgess burgess@hrd769.brooks.af.mil
-
-
-
- Dave Chapeskie dchapes@ddm.on.ca
-
-
-
- Dave Edmondson davided@sco.com
-
-
-
- Dave Rivers rivers@ponds.uucp
-
-
-
- David A. Bader dbader@umiacs.umd.edu
-
-
-
- David Dawes dawes@physics.su.OZ.AU
-
-
-
- David Holloway daveh@gwythaint.tamis.com
-
-
-
- David Leonard d@scry.dstc.edu.au
-
-
-
- Dean Huxley dean@fsa.ca
-
-
-
- Dima Sivachenko demon@gpad.ac.ru
-
-
-
- Dirk Froemberg dirk@hal.in-berlin.de
-
-
-
- Dmitry Kohmanyuk dk@farm.org
-
-
-
- Dom Mitchell dom@myrddin.demon.co.uk
-
-
-
- Don Croyle croyle@gelemna.ft-wayne.in.us
-
-
-
- &a.whiteside;
-
-
-
- Don Yuniskis dgy@rtd.com
-
-
-
- Donald Maddox dmaddox@scsn.net
-
-
-
- Doug Ambrisko ambrisko@ambrisko.roble.com
-
-
-
- Douglas Carmichael dcarmich@mcs.com
-
-
-
- Eckart “Isegrim” Hofmann
- Isegrim@Wunder-Nett.org
-
-
-
- Eiji-usagi-MATSUmoto usagi@clave.gr.jp
-
-
-
- ELISA Font Project
-
-
-
- Eric A. Griff eagriff@global2000.net
-
-
-
- Eric Blood eblood@cs.unr.edu
-
-
-
- Eric J. Chet ejc@bazzle.com
-
-
-
- Eric J. Schwertfeger eric@cybernut.com
-
-
-
- Francis M J Hsieh mjhsieh@life.nthu.edu.tw
-
-
-
- Frank Bartels knarf@camelot.de
-
-
-
- Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw
-
-
-
- Frank Maclachlan fpm@crash.cts.com
-
-
-
- Frank Nobis fn@trinity.radio-do.de
-
-
-
- Frank Volf volf@oasis.IAEhv.nl
-
-
-
- FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp
-
-
-
- FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp
-
-
-
- Gary A. Browning gab10@griffcd.amdahl.com
-
-
-
- Gary Kline kline@thought.org
-
-
-
- Gerard Roudier groudier@club-internet.fr
-
-
-
- Gilad Rom rom_glsa@ein-hashofet.co.uk
-
-
-
- Ginga Kawaguti
- ginga@amalthea.phys.s.u-tokyo.ac.jp
-
-
-
- Glenn Johnson gljohns@bellsouth.net
-
-
-
- Greg Ungerer gerg@stallion.oz.au
-
-
-
- Hans Huebner hans@artcom.de
-
-
-
- Hans Petter Bieker hanspb@persbraten.vgs.no
-
-
-
- Harlan Stenn Harlan.Stenn@pfcs.com
-
-
-
- Havard Eidnes Havard.Eidnes@runit.sintef.no
-
-
-
- Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp
-
-
-
- Hidekazu Kuroki hidekazu@cs.titech.ac.jp
-
-
-
- Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
-
-
-
- Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
-
-
-
- Hironori Ikura hikura@kaisei.org
-
-
-
- Hiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jp
-
-
-
- Holger Veit Holger.Veit@gmd.de
-
-
-
- HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp
-
-
-
- Horance Chou horance@freedom.ie.cycu.edu.tw
-
-
-
- Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw
-
-
-
- Ian Struble ian@broken.net
-
-
-
- Ian Vaudrey i.vaudrey@bigfoot.com
-
-
-
- Igor Vinokurov igor@zynaps.ru
-
-
-
- Ikuo Nakagawa ikuo@isl.intec.co.jp
-
-
-
- IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp
-
-
-
- Ishii Masahiro
-
-
-
- Iseei Suzuki issei@jp.FreeBSD.ORG
-
-
-
- Itsuro Saito saito@miv.t.u-tokyo.ac.jp
-
-
-
- J. David Lowe lowe@saturn5.com
-
-
-
- J. Han jtc@cygnus.com
-
-
-
- J.T. Conklin jtc@cygnus.com
-
-
-
- J.T. Lang keith@email.gcn.net.tw
-
-
-
- James Clark jjc@jclark.com
-
-
-
- James da Silva jds@cs.umd.edu et al
-
-
-
- Janusz Kokot janek@gaja.ipan.lublin.pl
-
-
-
- Jason Thorpe thorpej@nas.nasa.gov
-
-
-
- Javier Martin Rueda jmrueda@diatel.upm.es
-
-
-
- Jeff Bartig jeffb@doit.wisc.edu
-
-
-
- Keff Kletsky Jeff@Wagsky.com
-
-
-
- Jeffrey Wheat jeff@cetlink.net
-
-
-
- Jeremy Lea reg@shale.csir.co.za
-
-
-
- Jerry Hicks jhicks@glenatl.glenayre.com
-
-
-
- Jian-Da Li jdli@csie.NCTU.edu.tw
-
-
-
- Jim Binkley jrb@cs.pdx.edu
-
-
-
- Jim Lowe james@cs.uwm.edu
-
-
-
- Jim Mock jim@phrantic.phear.net
-
-
- Jim Wilson wilson@moria.cygnus.com
-
-
-
- Jimbo Bahooli
- griffin@blackhole.iceworld/org
-
-
-
- Joao Carlos Mendes Luis jonny@coppe.ufrj.br
-
-
-
- Joe Abley jabley@clear.co.nz
-
-
-
- Joe “Marcus” Clarke
- marcus@miami.edu
-
-
-
- Joe Jih-Shian Lu jslu@dns.ntu.edu.tw
-
-
-
- Joel Sutton sutton@aardvark.apana.org.au
-
-
-
- Johann Tonsing jtonsing@mikom.csir.co.za
-
-
-
- John Capo jc@irbs.com
-
-
-
- John Heidemann johnh@isi.edu
-
-
-
- John Hood cgull@owl.org
-
-
-
- John Perry perry@vishnu.alias.net
-
-
-
- John Polstra jdp@polstra.com
-
-
-
- John Rochester jr@cs.mun.ca
-
-
-
- John Saunders john@pacer.nlc.net.au
-
-
-
- Jonathan Hanna
- jh@pc-21490.bc.rogers.wave.ca
-
-
-
- Josef Karthauser joe@uk.freebsd.org
-
-
-
- Joseph Stein joes@seaport.net
-
-
-
- Josh Gilliam josh@quick.net
-
-
-
- Josh Tiefenbach josh@ican.net
-
-
-
- Juergen Lock nox@jelal.hb.north.de
-
-
-
- Juha Inkari inkari@cc.hut.fi
-
-
-
- Julian Assange proff@suburbia.net
-
-
-
- Julian Jenkins kaveman@magna.com.au
-
-
-
- Julian Stacey jhs@freebsd.org
-
-
-
- Junichi Satoh junichi@jp.freebsd.org
-
-
-
- Junya WATANABE junya-w@remus.dti.ne.jp
-
-
-
- Kapil Chowksey kchowksey@hss.hns.com
-
-
-
- Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp
-
-
-
- Keith Bostic bostic@bostic.com
-
-
-
- Keith Moore
-
-
-
- Kenneth Monville desmo@bandwidth.org
-
-
-
- Kent Vander Velden graphix@iastate.edu
-
-
-
- Kentaro Inagaki JBD01226@niftyserve.ne.jp
-
-
-
- Kirk McKusick mckusick@mckusick.com
-
-
-
- Kiroh HARADA kiroh@kh.rim.or.jp
-
-
-
- Koichi Sato copan@ppp.fastnet.or.jp
-
-
-
- Kostya Lukin lukin@okbmei.msk.su
-
-
-
- KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
-
-
-
- Kurt Olsen kurto@tiny.mcs.usu.edu
-
-
-
- Lars Köller Lars.Koeller@Uni-Bielefeld.DE
-
-
-
- Lian Tai-hwa
- avatar@www.mmlab.cse.yzu.edu.twu
-
-
-
- Lucas James Lucas.James@ldjpc.apana.org.au
-
-
-
- Luigi Rizzo luigi@iet.unipi.it
-
-
-
- Malte Lance malte.lance@gmx.net
-
-
-
- Makoto MATSUSHITA matusita@jp.freebsd.org
-
-
-
- Makoto WATANABE
- watanabe@zlab.phys.nagoya-u.ac.jp
-
-
-
- MANTANI Nobutaka nobutaka@nobutaka.com
-
-
-
- Manu Iyengar iyengar@grunthos.pscwa.psca.com
-
-
-
- Marc Frajola marc@dev.com
-
-
-
- Marc Ramirez mrami@mramirez.sy.yale.edu
-
-
-
- Marc Slemko marcs@znep.com
-
-
-
- Marc van Kempen wmbfmk@urc.tue.nl
-
-
-
- Mario Sergio Fujikawa Ferreira lioux@gns.com.br
-
-
-
- Mark Huizer xaa@stack.nl
-
-
-
- Mark J. Taylor mtaylor@cybernet.com
-
-
-
- Mark Krentel krentel@rice.edu
-
-
-
- Mark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.edu
-
-
-
- Martin Birgmeier
-
-
-
- Martti Kuparinen erakupa@kk.etx.ericsson.se
-
-
-
- Masachika ISHIZUKA ishizuka@isis.min.ntt.jp
-
-
-
- Masanori Kiriake seiken@ncs.co.jp
-
-
-
- Mats Lofkvist mal@algonet.se
-
-
-
- Matt Bartley mbartley@lear35.cytex.com
-
-
-
- Matt Thomas thomas@lkg.dec.com
-
-
-
- Matt White mwhite+@CMU.EDU
-
-
-
- Matthew N. Dodd winter@jurai.net
-
-
-
- Matthew Stein matt@bdd.net
-
-
-
- Maurice Castro maurice@planet.serc.rmit.edu.au
-
-
-
- Michael Butschky butsch@computi.erols.com
-
-
-
- Michael Elbel me@FreeBSD.ORG
-
-
-
- Michael Searle searle@longacre.demon.co.uk
-
-
-
- Miguel Angel Sagreras msagre@cactus.fi.uba.ar
-
-
-
- Mikael Hybsch micke@dynas.se
-
-
-
- Mikhail Teterin mi@aldan.ziplink.net
-
-
-
- Mike McGaughey mmcg@cs.monash.edu.au
-
-
-
- Mike Peck mike@binghamton.edu
-
-
-
- Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW
-
-
-
- MITA Yoshio mita@jp.FreeBSD.ORG
-
-
-
- MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp
-
-
-
- Motoyuki Kasahara m-hasahr@sra.co.jp
-
-
-
- Munechika Sumikawa sumikawa@kame.net
-
-
-
- Murray Stokely murray@cdrom.com
-
-
-
- NAKAMURA Kazushi nkazushi@highway.or.jp
-
-
-
- Naoki Hamada nao@tom-yam.or.jp
-
-
-
- Narvi narvi@haldjas.folklore.ee
-
-
-
- NIIMI Satoshi sa2c@and.or.jp
-
-
-
- Nick Sayer nsayer@quack.kfu.com
-
-
-
- Nicolas Souchu Nicolas.Souchu@prism.uvsq.fr
-
-
-
- Nisha Talagala nisha@cs.berkeley.edu
-
-
-
- Nobuhiro Yasutomi nobu@psrc.isac.co.jp
-
-
-
- Nobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
-
-
- Norio Suzuki nosuzuki@e-mail.ne.jp
-
-
-
- Noritaka Ishizumi graphite@jp.FreeBSD.ORG
-
-
-
- Oliver Breuninger ob@seicom.NET
-
-
-
- Oliver Fromme oliver.fromme@heim3.tu-clausthal.de
-
-
-
- Oliver Laumann net@informatik.uni-bremen.de
-
-
-
- Oliver Oberdorf oly@world.std.com
-
-
-
- Palle Girgensohn girgen@partitur.se
-
-
-
- Paul Fox pgf@foxharp.boston.ma.us
-
-
-
- Paul Kranenburg pk@cs.few.eur.nl
-
-
-
- Paul Mackerras paulus@cs.anu.edu.au
-
-
-
- Paulo Menezes paulo@isr.uc.pt
-
-
-
- Paul T. Root proot@horton.iaces.com
-
-
-
- Pedro Giffuni giffunip@asme.org
-
-
-
- Pedro A M Vazquez vazquez@IQM.Unicamp.BR
-
-
-
- Peter Cornelius pc@inr.fzk.de
-
-
-
- Peter Haight peterh@prognet.com
-
-
-
- Peter Stubbs PETERS@staidan.qld.edu.au
-
-
-
- Pierre Beyssac bp@fasterix.freenix.org
-
-
-
- Phil Maker pjm@cs.ntu.edu.au
-
-
-
- R. Kym Horsell
-
-
-
- Randall Hopper rhh@stealth.ct.picker.com
-
-
-
- Ricardas Cepas rch@richard.eu.org
-
-
-
- Richard Hwang rhwang@bigpanda.com
-
-
-
- Richard. M. Neswold rneswold@drmemory.fnal.gov
-
-
-
- Richard Seaman, Jr. dick@tar.com
-
-
-
- Richard Stallman rms@gnu.ai.mit.edu
-
-
-
- Richard Wiwatowski rjwiwat@adelaide.on.net
-
-
-
- Rob Mallory rmallory@csusb.edu
-
-
-
- Rob Shady rls@id.net
-
-
-
- Rob Snow rsnow@txdirect.net
-
-
-
- Robert Sanders rsanders@mindspring.com
-
-
-
- Robert Withrow witr@rwwa.com
-
-
-
- Ronald Kuehn kuehn@rz.tu-clausthal.de
-
-
-
- Roland Jesse jesse@cs.uni-magdeburg.de
-
-
-
- Ruslan Shevchenko rssh@cki.ipri.kiev.ua
-
-
-
- SURANYI Peter suranyip@jks.is.tsukuba.ac.jp
-
-
-
- Samuel Lam skl@ScalableNetwork.com
-
-
-
- Sander Vesik sander@haldjas.folklore.ee
-
-
-
- Sandro Sigala ssigala@globalnet.it
-
-
-
- Sascha Blank blank@fox.uni-trier.de
-
-
-
- Sascha Wildner swildner@channelz.GUN.de
-
-
-
- Satoshi Taoka taoka@infonets.hiroshima-u.ac.jp
-
-
-
- Satsuki FUJISHIMA k5@respo.or.jp
-
-
-
- Scot W. Hetzel hetzels@westbend.net
-
-
-
- Scott Blachowicz scott.blachowicz@seaslug.org
-
-
-
- Scott A. Kenney saken@rmta.ml.org
-
-
-
- Seigou TANIMURA
- tanimura@naklab.dnj.ynu.ac.jp
-
-
-
- Serge Babkin babkin@hq.icb.chel.su
-
-
-
- Serge V. Vakulenko vak@zebub.msk.su
-
-
-
- Sheldon Hearn axl@iafrica.com
-
-
-
- Shigeyuki FUKUSHIMA
- shige@kuis.kyoto-u.ac.jp
-
-
-
- Simon Marlow simonm@dcs.gla.ac.uk
-
-
-
- Slaven Rezic (Tomic) eserte@cs.tu-berlin.de
-
-
-
- Soren Dayton csdayton@midway.uchicago.edu
-
-
-
- Soren Dossing sauber@netcom.com
-
-
-
- Stefan Eggers seggers@semyam.dinoco.de
-
-
-
- Stefan Moeding s.moeding@ndh.net
-
-
-
- Stefan “Sec” Zehl sec@42.org
-
-
-
- Stephane Legrand stephane@lituus.fr
-
-
-
- Stephen Farrell stephen@farrell.org
-
-
-
- Stephen J. Roznowski sjr@home.net
-
-
-
- Steve Gerakines steve2@genesis.tiac.net
-
-
-
- Steven G. Kargl
- kargl@troutmask.apl.washington.edu
-
-
-
- Stephen H. Samorodin samorodi@NUXU.com
-
-
-
- Stuart Henderson
- stuart@internationalschool.co.uk
-
-
-
- SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
-
-
-
- Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp
-
-
-
- Tadashi Kumano kumano@strl.nhk.or.jp
-
-
-
- Taguchi Takeshi taguchi@tohoku.iij.ad.jp
-
-
-
- Takashi Mega mega@minz.org
-
-
-
- Takashi Uozu j1594016@ed.kagu.sut.ac.jp
-
-
-
- Takayuki Ariga a00821@cc.hc.keio.ac.jp
-
-
-
- Takeu NAIKI naiki@bfd.es.hokudai.ac.jp
-
-
-
- Ted Faber faber@ISI.EDU
-
-
-
- Terry Lambert terry@lambert.org
-
-
-
- Terry Lee terry@uivlsi.csl.uiuc.edu
-
-
-
- Tetsuya Furukawa tetsuya@secom-sis.co.jp
-
-
-
- Theo Deraadt deraadt@fsa.ca
-
-
-
- Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de
-
-
-
- Þórður Ívarsson totii@est.is
-
-
-
- Tim Kientzle kientzle@netcom.com
-
-
-
- Tim Wilkinson tim@sarc.city.ac.uk
-
-
-
- Tom Hukins tom@eborcom.com
-
-
-
- Tom Jobbins tom@tom.tj
-
-
-
- Tom Samplonius tom@misery.sdf.com
-
-
-
- Torbjorn Granlund tege@matematik.su.se
-
-
-
- Toshihiro Kanda candy@fct.kgc.co.jp
-
-
-
- Toshihiko SHIMOKAWA toshi@tea.forus.or.jp
-
-
-
- Trefor S. trefor@flevel.co.uk
-
-
-
- Vadim Chekan vadim@gc.lviv.ua
-
-
-
- Ville Eerola ve@sci.fi
-
-
-
- Vladimir Kushnir kushn@mail.kar.net
-
-
-
- Werner Griessl werner@btp1da.phy.uni-bayreuth.de
-
-
-
- Wes Santee wsantee@wsantee.oz.net
-
-
-
- Wilko Bulte wilko@yedi.iaf.nl
-
-
-
- Wolfgang Stanglmeier wolf@kintaro.cologne.de
-
-
-
- Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW
-
-
-
- Yen-Shuo Su yssu@CCCA.NCTU.edu.tw
-
-
-
- Ying-Chieh Liao ijliao@csie.NCTU.edu.tw
-
-
-
- Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp
-
-
-
- Yoshiro Mihira sanpei@yy.cs.keio.ac.jp
-
-
-
- Yukihiro Nakai nakai@iname.com
-
-
-
- Yusuke Nawano azuki@azkey.org
-
-
-
- Yuval Yarom yval@cs.huji.ac.il
-
-
-
- Yves Fonk yves@cpcoup5.tn.tudelft.nl
- 386BSD 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 9b94ec57b4..36e43e6314 100644
--- a/en_US.ISO8859-1/books/handbook/authors.ent
+++ b/en_US.ISO8859-1/books/handbook/authors.ent
@@ -1,338 +1,344 @@
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">
+dcs@FreeBSD.ORG">
+
des@FreeBSD.ORG">
dfr@FreeBSD.ORG">
+dg@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">
+eivind@FreeBSD.ORG">
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@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">
+kris@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">
+shige@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 64de53ef79..6f5c05ed25 100644
--- a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
@@ -1,531 +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), 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
+ URL="http://www.cdrom.com/titles/freebsd/bsdbook2.htm">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-7Jpman 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 fb72c6e754..a16117c8ed 100644
--- a/en_US.ISO8859-1/books/handbook/book.sgml
+++ b/en_US.ISO8859-1/books/handbook/book.sgml
@@ -1,112 +1,114 @@
%chapters;
%authors;
%mailing-lists;
+ %newsgroups;
-
+
]>
FreeBSD HandbookThe FreeBSD Documentation Project
- July 1998
+ February 19991995199619971998
+ 1999The 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
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 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 ad9ec398bc..6d64db5434 100644
--- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
@@ -1,2954 +1,2558 @@
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;
+ Coordinator: &a.eivind;
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;
- Implement Int13 vm86 disk driver. Coordinator:
- &a.hackers;
+ New bus architecture. Coordinator: &a.newbus;
+
+
+
+ Port existing ISA drivers to new
+ architecture.
+
+
+
+ Move all interrupt-management code to appropriate
+ parts of the bus drivers.
+
+
+
+ Port PCI subsystem to new architecture. Coordinator:
+ &a.dfr;
+
+
+
+ Figure out the right way to handle removable devices
+ and then use that as a substrate on which PC-Card and
+ CardBus support can be implemented.
+
+
+
+ Resolve the probe/attach priority issue once and for
+ all.
+
+
+
+ Move any remaining buses over to the new
+ architecture.
+
+ 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).
-
-
-
-
-
-
+
+
+ Add more pro-active security infrastructure. Overall
+ coordination: &a.security;
+
+
+
+ Build something like Tripwire(TM) into the kernel,
+ with a remote and local part. There are a number of
+ cryptographic issues to getting this right; contact the
+ coordinator for details. Coordinator: &a.eivind;
+
+
+
+ Make the entire kernel use
+ suser() instead of comparing to 0. It
+ is presently using about half of each. Coordinator:
+ &a.eivind;
+
+
+
+ Split securelevels into different parts, to allow an
+ administrator to throw away those privileges he can throw
+ away. Setting the overall securelevel needs to have the
+ same effect as now, obviously. Coordinator:
+ &a.eivind;
+
+
+
+ Make it possible to upload a list of “allowed
+ program” to BPF, and then block BPF from accepting
+ other programs. This would allow BPF to be used e.g. for
+ DHCP, without allowing an attacker to start snooping the
+ local network.
+
+
+
+ Update the security checker script. We should at
+ least grab all the checks from the other BSD derivatives,
+ and add checks that a system with securelevel increased
+ also have reasonable flags on the relevant parts.
+ Coordinator: &a.eivind;
+
+
+
+ Add authorization infrastructure to the kernel, to
+ allow different authorization policies. Part of this
+ could be done by modifying suser().
+ Coordinatory: &a.eivind;
+
+
+
+ Add code to teh NFS layer so that you cannot
+ chdir("..") out of an NFS partition.
+ E.g., /usr is a UFS partition with
+ /usr/src NFS exported. Now it is
+ possible to use the NFS filehandle for
+ /usr/src to get access to
+ /usr.
+
+
+
+
+
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.com
-
-
-
- MCA support? This should be finalized one way or the
- other.
-
-
- Full LKM based driver support/Configuration Manager.
-
+ Full KLD 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,
+ keeps only the KLDs 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
+ The first N items are from Terry Lambert
terry@lambert.org
-
-
- Ability 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
+ Read the freebsd-questions mailing list and &ng.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.<anchor id="donations">Donating funds
- While the FreeBSD Project is not a 501(C3) (non-profit)
+ While the FreeBSD Project is not a 501(c)(3) (charitable)
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.BuffNETPacific
SolutionsHardware 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!
+ ATM switch for debugging the diskless code.
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.
-
+
+
+ Core Team Alumnus
+
+ The following people were members of the FreeBSD core team
+ during the period indicated. We thank them for their past efforts in
+ the service of the FreeBSD project.
+
+ In rough chronological order:
+
+
+
+ Guido van Rooij (1995 - 1999)
+
+
+
+ John Dyson (1993 - 1998)
+
+
+
+ Nate Williams (1992 - 1996)
+
+
+
+ Rod Grimes (1992 - 1995)
+
+
+
+ Andreas Schulz (1992 - 1995)
+
+
+
+ Geoff Rehmet (1993 - 1995)
+
+
+
+ Paul Richards (1992 - 1995)
+
+
+
+ Scott Mace (1993 - 1994)
+
+
+
+ Andrew Moore (1993 - 1994)
+
+
+
+ Christoph Robitschko (1993 - 1994)
+
+
+
+ J. T. Conklin (1992 - 1993)
+
+
+
+
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.jp
-
-
-
- Ada T Lim ada@bsd.org
-
-
-
- Adam Glass glass@postgres.berkeley.edu
-
-
-
- Adam McDougall mcdouga9@egr.msu.edu
-
-
-
- Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu
-
-
-
- Akito Fujita fujita@zoo.ncl.omron.co.jp
-
-
-
- Alain Kalker A.C.P.M.Kalker@student.utwente.nl
-
-
-
- Alan Cox alc@cs.rice.edu
-
-
-
- Amancio Hasty ahasty@freebsd.org
-
-
-
- Andreas Kohout shanee@rabbit.augusta.de
-
-
-
- Andreas Lohr andreas@marvin.RoBIN.de
-
-
-
- Andrew Gallatin gallatin@cs.duke.edu
-
-
-
- Andrew Gordon andrew.gordon@net-tel.co.uk
-
-
-
- Andrew Herbert andrew@werple.apana.org.au
-
-
-
- Andrew McRae amcrae@cisco.com
-
-
-
- Andrew Moore alm@FreeBSD.org
-
-
-
- Andrew Stevenson andrew@ugh.net.au
-
-
-
- Andrew V. Stesin stesin@elvisti.kiev.ua
-
-
-
- Andrey Zakhvatov andy@icc.surw.chel.su
-
-
-
- Andy Whitcroft andy@sarc.city.ac.uk
-
-
-
- Angelo Turetta ATuretta@stylo.it
-
-
-
- Anthony C. Chavez magus@xmission.com
-
-
-
- Anthony Yee-Hang Chan yeehang@netcom.com
-
-
-
- Anton Berezin tobez@plab.ku.dk
-
-
-
- Ari Suutari ari@suutari.iki.fi
-
-
-
- Ben Hutchinson benhutch@xfiles.org.uk
-
-
-
- Bernd Rosauer br@schiele-ct.de
-
-
- Bill Kish kish@osf.org
-
+ ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp
+ AMAGAI Yoshiji amagai@nue.org
+ Aaron Bornstein aaronb@j51.com
+ Aaron Smith aaron@tau.veritas.com
+ Achim Patzner ap@noses.com
+ Ada T Lim ada@bsd.org
+ Adam Baran badam@mw.mil.pl
+ Adam Glass glass@postgres.berkeley.edu
+ Adam McDougall mcdouga9@egr.msu.edu
+ Adrian Colley aecolley@ois.ie
+ Adrian Hall adrian@ibmpcug.co.uk
+ Adrian Mariano adrian@cam.cornell.edu
+ Adrian Steinmann ast@marabu.ch
+ Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu
+ Ajit Thyagarajan
+ Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp
+ Akira SAWADA
+ Akira Watanabe akira@myaw.ei.meisei-u.ac.jp
+ Akito Fujita fujita@zoo.ncl.omron.co.jp
+ Alain Kalker A.C.P.M.Kalker@student.utwente.nl
+ Alan Bawden alan@curry.epilogue.com
+ Alan Cox alc@cs.rice.edu
+ Alec Wolman wolman@cs.washington.edu
+ Aled Morris aledm@routers.co.uk
+ Alex garbanzo@hooked.net
+ Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw
+ Alex G. Bulushev bag@demos.su
+ Alex Le Heux alexlh@funk.org
+ Alexander B. Povolotsky tarkhil@mgt.msk.ru
+ Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE
+ Alexandre Snarskii snar@paranoia.ru
+ Alistair G. Crooks agc@uts.amdahl.com
+ Allan Saddi asaddi@philosophysw.com
+ Allen Campbell allenc@verinet.com
+ Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp
+ Amancio Hasty hasty@star-gate.com
+ Amir Farah amir@comtrol.com
+ Amy Baron amee@beer.org
+ Anatoly A. Orehovsky tolik@mpeks.tomsk.su
+ Anatoly Vorobey mellon@pobox.com
+ Anders Nordby nickerne@nome.no
+ Anders Thulin Anders.X.Thulin@telia.se
+ Andras Olah olah@cs.utwente.nl
+ Andre Albsmeier Andre.Albsmeier@mchp.siemens.de
+ Andre Oppermann andre@pipeline.ch
+ Andreas Haakh ah@alman.robin.de
+ Andreas Kohout shanee@rabbit.augusta.de
+ Andreas Lohr andreas@marvin.RoBIN.de
+ Andreas Schulz
+ Andreas Wetzel mickey@deadline.snafu.de
+ Andreas Wrede andreas@planix.com
+ Andres Vega Garcia
+ Andrew Atrens atreand@statcan.ca
+ Andrew Gillham gillham@andrews.edu
+ Andrew Gordon andrew.gordon@net-tel.co.uk
+ Andrew Herbert andrew@werple.apana.org.au
+ Andrew J. Korty ajk@purdue.edu
+ Andrew L. Moore alm@mclink.com
+ Andrew McRae amcrae@cisco.com
+ Andrew Stevenson andrew@ugh.net.au
+ Andrew Timonin tim@pool1.convey.ru
+ Andrew V. Stesin stesin@elvisti.kiev.ua
+ Andrew Webster awebster@dataradio.com
+ Andrey Zakhvatov andy@icc.surw.chel.su
+ Andy Farkas andyf@speednet.com.au
+ Andy Valencia ajv@csd.mot.com
+ Andy Whitcroft andy@sarc.city.ac.uk
+ Angelo Turetta ATuretta@stylo.it
+ Anthony C. Chavez magus@xmission.com
+ Anthony Yee-Hang Chan yeehang@netcom.com
+ Anton Berezin tobez@plab.ku.dk
+ Antti Kaipila anttik@iki.fi
+ Are Bryne are.bryne@communique.no
+ Ari Suutari ari@suutari.iki.fi
+ Arjan de Vet devet@IAEhv.nl
+ Arne Henrik Juul arnej@Lise.Unit.NO
+ Assar Westerlund assar@sics.se
+ Atsushi Furuta furuta@sra.co.jp
+ Atsushi Murai amurai@spec.co.jp
+ Bakul Shah bvs@bitblocks.com
+ Barry Bierbauch pivrnec@vszbr.cz
+ Barry Lustig barry@ictv.com
+ Ben Hutchinson benhutch@xfiles.org.uk
+ Ben Jackson
+ Ben Smithurst ben@scientia.demon.co.uk
+ Ben Walter bwalter@itachi.swcp.com
+ Benjamin Lewis bhlewis@gte.net
+ Bernd Rosauer br@schiele-ct.de
+ Bill Kish kish@osf.org
+ Bill Trost trost@cloud.rain.com
+ Blaz Zupan blaz@amis.net
+ Bob Van Valzah Bob@whitebarn.com
+ Bob Willcox bob@luke.pmr.com
+ Boris Staeblow balu@dva.in-berlin.de
+ Boyd R. Faulkner faulkner@asgard.bga.com
+ Brad Karp karp@eecs.harvard.edu
+ Bradley Dunn bradley@dunn.org
+ Brandon Gillespie brandon@roguetrader.com
+ &a.wlloyd
+ Bob Wilcox bob@obiwan.uucp
+ Boyd Faulkner faulkner@mpd.tandem.com
+ Brent J. Nordquist bjn@visi.com
+ Brett Lymn blymn@mulga.awadi.com.AU
+ Brett Taylor brett@peloton.physics.montana.edu
+ Brian Campbell brianc@pobox.com
+ Brian Clapper bmc@willscreek.com
+ Brian Cully shmit@kublai.com
+ Brian F. Feldman green@unixhelp.org
+ Brian Handy handy@lambic.space.lockheed.com
+ Brian Litzinger brian@MediaCity.com
+ Brian McGovern bmcgover@cisco.com
+ Brian Moore ziff@houdini.eecs.umich.edu
+ Brian R. Haug haug@conterra.com
+ Brian Tao taob@risc.org
+ Brion Moss brion@queeg.com
+ Bruce A. Mah bmah@ca.sandia.gov
+ Bruce Albrecht bruce@zuhause.mn.org
+ Bruce Gingery bgingery@gtcs.com
+ Bruce J. Keeler loodvrij@gridpoint.com
+ Bruce Murphy packrat@iinet.net.au
+ Bruce Walter walter@fortean.com
+ Carey Jones mcj@acquiesce.org
+ Carl Fongheiser cmf@netins.net
+ Carl Mascott cmascott@world.std.com
+ Casper casper@acc.am
+ Castor Fu castor@geocast.com
+ Cejka Rudolf cejkar@dcse.fee.vutbr.cz
+ Chain Lee chain@110.net
+ Charles Hannum mycroft@ai.mit.edu
+ Charles Henrich henrich@msu.edu
+ Charles Mott cmott@srv.net
+ Charles Owens owensc@enc.edu
+ Chet Ramey chet@odin.INS.CWRU.Edu
+ Chia-liang Kao clkao@CirX.ORG
+ Chiharu Shibata chi@bd.mbn.or.jp
+ Chip Norkus
+ Choi Jun Ho junker@jazz.snu.ac.kr
+ Chris Csanady cc@tarsier.ca.sandia.gov
+ Chris Dabrowski chris@vader.org
+ Chris Dillon cdillon@wolves.k12.mo.us
+ Chris Piazza cpiazza@home.net
+ Chris Shenton cshenton@angst.it.hq.nasa.gov
+ Chris Stenton jacs@gnome.co.uk
+ Chris Timmons skynyrd@opus.cts.cwu.edu
+ Chris Torek torek@ee.lbl.gov
+ Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at
+ Christian Haury Christian.Haury@sagem.fr
+ Christian Weisgerber naddy@bigeye.rhein-neckar.de
+ Christoph P. Kukulies kuku@FreeBSD.org
+ Christoph Robitschko chmr@edvz.tu-graz.ac.at
+ Christoph Weber-Fahr wefa@callcenter.systemhaus.net
+ Christopher G. Demetriou cgd@postgres.berkeley.edu
+ Christopher T. Johnson cjohnson@neunacht.netgsi.com
+ Chrisy Luke chrisy@flix.net
+ Chuck Hein chein@cisco.com
+ Clive Lin clive@CiRX.ORG
+ Colman Reilly careilly@tcd.ie
+ Conrad Sabatier conrads@neosoft.com
+ Coranth Gryphon gryphon@healer.com
+ Cornelis van der Laan nils@guru.ims.uni-stuttgart.de
+ Cove Schneider cove@brazil.nbn.com
+ Craig Leres leres@ee.lbl.gov
+ Craig Loomis
+ Craig Metz cmetz@inner.net
+ Craig Spannring cts@internetcds.com
+ Craig Struble cstruble@vt.edu
+ Cristian Ferretti cfs@riemann.mat.puc.cl
+ Curt Mayer curt@toad.com
+ Cy Schubert cschuber@uumail.gov.bc.ca
+ DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at
+ Dai Ishijima ishijima@tri.pref.osaka.jp
+ Damian Hamill damian@cablenet.net
+ Dan Cross tenser@spitfire.ecsel.psu.edu
+ Dan Lukes dan@obluda.cz
+ Dan Nelson dnelson@emsphone.com
+ Dan Walters hannibal@cyberstation.net
+ Daniel Baker dbaker@crash.ops.neosoft.com
+ Daniel M. Eischen deischen@iworks.InterWorks.org
+ Daniel O'Connor doconnor@gsoft.com.au
+ Daniel Poirot poirot@aio.jsc.nasa.gov
+ Daniel Rock rock@cs.uni-sb.de
+ Danny Egen
+ Danny J. Zerkel dzerkel@phofarm.com
+ Darren Reed avalon@coombs.anu.edu.au
+ Dave Adkins adkin003@tc.umn.edu
+ Dave Andersen angio@aros.net
+ Dave Blizzard dblizzar@sprynet.com
+ Dave Bodenstab imdave@synet.net
+ Dave Burgess burgess@hrd769.brooks.af.mil
+ Dave Chapeskie dchapes@ddm.on.ca
+ Dave Cornejo dave@dogwood.com
+ Dave Edmondson davided@sco.com
+ Dave Glowacki dglo@ssec.wisc.edu
+ Dave Marquardt marquard@austin.ibm.com
+ Dave Tweten tweten@FreeBSD.org
+ David A. Adkins adkin003@tc.umn.edu
+ David A. Bader dbader@umiacs.umd.edu
+ David Borman dab@bsdi.com
+ David Dawes dawes@XFree86.org
+ David Filo filo@yahoo.com
+ David Holland dholland@eecs.harvard.edu
+ David Holloway daveh@gwythaint.tamis.com
+ David Horwitt dhorwitt@ucsd.edu
+ David Hovemeyer daveho@infocom.com
+ David Jones dej@qpoint.torfree.net
+ David Kelly dkelly@tomcat1.tbe.com
+ David Kulp dkulp@neomorphic.com
+ David L. Nugent davidn@blaze.net.au
+ David Leonard d@scry.dstc.edu.au
+ David Malone dwmalone@maths.tcd.ie
+ David Muir Sharnoff muir@idiom.com
+ David S. Miller davem@jenolan.rutgers.edu
+ David Wolfskill dhw@whistle.com
+ Dean Gaudet dgaudet@arctic.org
+ Dean Huxley dean@fsa.ca
+ Denis Fortin
+ Dennis Glatting dennis.glatting@software-munitions.com
+ Denton Gentry denny1@home.com
+ Derek Inksetter derek@saidev.com
+ Dima Sivachenko dima@Chg.RU
+ Dirk Keunecke dk@panda.rhein-main.de
+ Dirk Nehrling nerle@pdv.de
+ Dmitry Khrustalev dima@xyzzy.machaon.ru
+ Dmitry Kohmanyuk dk@farm.org
+ Dom Mitchell dom@myrddin.demon.co.uk
+ Don Croyle croyle@gelemna.ft-wayne.in.us
+ &a.whiteside;
+ Don Morrison dmorrisn@u.washington.edu
+ Don Yuniskis dgy@rtd.com
+ Donald Maddox dmaddox@conterra.com
+ Doug Barton studded@dal.net
+ Douglas Ambrisko ambrisko@whistle.com
+ Douglas Carmichael dcarmich@mcs.com
+ Douglas Crosher dtc@scrooge.ee.swin.oz.au
+ Drew Derbyshire ahd@kew.com
+ Duncan Barclay dmlb@ragnet.demon.co.uk
+ Dustin Sallings dustin@spy.net
+ Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org
+ Ed Gold vegold01@starbase.spd.louisville.edu
+ Ed Hudson elh@p5.spnet.com
+ Edward Wang edward@edcom.com
+ Edwin Groothus edwin@nwm.wan.philips.com
+ Eiji-usagi-MATSUmoto usagi@clave.gr.jp
+ ELISA Font Project
+ Elmar Bartel bartel@informatik.tu-muenchen.de
+ Eric A. Griff eagriff@global2000.net
+ Eric Blood eblood@cs.unr.edu
+ Eric J. Haug ejh@slustl.slu.edu
+ Eric J. Schwertfeger eric@cybernut.com
+ Eric L. Hernes erich@lodgenet.com
+ Eric P. Scott eps@sirius.com
+ Eric Sprinkle eric@ennovatenetworks.com
+ Erich Stefan Boleyn erich@uruk.org
+ Erik E. Rantapaa rantapaa@math.umn.edu
+ Erik H. Moe ehm@cris.com
+ Ernst Winter ewinter@lobo.muc.de
+ Eugene M. Kim astralblue@usa.net
+ Eugene Radchenko genie@qsar.chem.msu.su
+ Evan Champion evanc@synapse.net
+ Faried Nawaz fn@Hungry.COM
+ Flemming Jacobsen fj@tfs.com
+ Fong-Ching Liaw fong@juniper.net
+ Francis M J Hsieh mjshieh@life.nthu.edu.tw
+ Frank Bartels knarf@camelot.de
+ Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw
+ Frank Durda IV uhclem@nemesis.lonestar.org
+ Frank MacLachlan fpm@n2.net
+ Frank Nobis fn@Radio-do.de
+ Frank Volf volf@oasis.IAEhv.nl
+ Frank ten Wolde franky@pinewood.nl
+ Frank van der Linden frank@fwi.uva.nl
+ Fred Cawthorne fcawth@jjarray.umn.edu
+ Fred Gilham gilham@csl.sri.com
+ Fred Templin templin@erg.sri.com
+ Frederick Earl Gray fgray@rice.edu
+ FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp
+ FUJISHIMA Satsuki k5@respo.or.jp
+ FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp
+ Gabor Kincses gabor@acm.org
+ Gabor Zahemszky zgabor@CoDe.hu
+ Garance A Drosehn gad@eclipse.its.rpi.edu
+ Gareth McCaughan gjm11@dpmms.cam.ac.uk
+ Gary A. Browning gab10@griffcd.amdahl.com
+ Gary Howland gary@hotlava.com
+ Gary J. garyj@rks32.pcs.dec.com
+ Gary Kline kline@thought.org
+ Gaspar Chilingarov nightmar@lemming.acc.am
+ Gea-Suan Lin gsl@tpts4.seed.net.tw
+ Geoff Rehmet csgr@alpha.ru.ac.za
+ Georg Wagner georg.wagner@ubs.com
+ Gerard Roudier groudier@club-internet.fr
+ Gianmarco Giovannelli gmarco@giovannelli.it
+ Gil Kloepfer Jr. gil@limbic.ssdl.com
+ Gilad Rom rom_glsa@ein-hashofet.co.il
+ Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp
+ Giles Lean giles@nemeton.com.au
+ Glen Foster gfoster@gfoster.com
+ Glenn Johnson gljohns@bellsouth.net
+ Godmar Back gback@facility.cs.utah.edu
+ Goran Hammarback goran@astro.uu.se
+ Gord Matzigkeit gord@enci.ucalgary.ca
+ Graham Wheeler gram@cdsec.com
+ Greg A. Woods woods@zeus.leitch.com
+ Greg Ansley gja@ansley.com
+ Greg Troxel gdt@ir.bbn.com
+ Greg Ungerer gerg@stallion.oz.au
+ Gregory Bond gnb@itga.com.au
+ Gregory D. Moncreaff moncrg@bt340707.res.ray.com
+ Guy Harris guy@netapp.com
+ Guy Helmer ghelmer@cs.iastate.edu
+ HAMADA Naoki hamada@astec.co.jp
+ HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp
+ HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp
+ Hannu Savolainen hannu@voxware.pp.fi
+ Hans Huebner hans@artcom.de
+ Hans Petter Bieker zerium@webindex.no
+ Hans Zuidam hans@brandinnovators.com
+ Harlan Stenn Harlan.Stenn@pfcs.com
+ Harold Barker hbarker@dsms.com
+ Havard Eidnes Havard.Eidnes@runit.sintef.no
+ Heikki Suonsivu hsu@cs.hut.fi
+ Heiko W. Rupp
+ Helmut F. Wirth hfwirth@ping.at
+ Henrik Vestergaard Draboel hvd@terry.ping.dk
+ Herb Peyerl hpeyerl@NetBSD.org
+ Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp
+ Hidekazu Kuroki hidekazu@cs.titech.ac.jp
+ Hideki Yamamoto hyama@acm.org
+ Hidetoshi Shimokawa simokawa@sat.t.u-tokyo.ac.jp
+ Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
+ Hirayama Issei iss@mail.wbs.ne.jp
+ Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
+ Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp
+ Hironori Ikura hikura@kaisei.org
+ Hiroshi Nishikawa nis@pluto.dti.ne.jp
+ Hiroya Tsubakimoto
+ Hiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jp
+ Holger Veit Holger.Veit@gmd.de
+ Holm Tiffe holm@geophysik.tu-freiberg.de
+ Horance Chou horance@freedom.ie.cycu.edu.tw
+ Horihiro Kumagaio kuma@jp.freebsd.org
+ Horikawa Kazuo k-horik@mail.yk.rim.or.jp
+ Hr.Ladavac lada@ws2301.gud.siemens.co.at
+ Hubert Feyrer hubertf@NetBSD.ORG
+ Hugh F. Mahon hugh@nsmdserv.cnd.hp.com
+ Hugh Mahon h_mahon@fc.hp.com
+ Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw
+ IMAI Takeshi take-i@ceres.dti.ne.jp
+ IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp
+ Ian Dowse iedowse@maths.tcd.ie
+ Ian Holland ianh@tortuga.com.au
+ Ian Struble ian@broken.net
+ Ian Vaudrey i.vaudrey@bigfoot.com
+ Igor Khasilev igor@jabber.paco.odessa.ua
+ Igor Roshchin str@giganda.komkon.org
+ Igor Sviridov siac@ua.net
+ Igor Vinokurov igor@zynaps.ru
+ Ikuo Nakagawa ikuo@isl.intec.co.jp
+ Ilya V. Komarov mur@lynx.ru
+ Issei Suzuki issei@jp.FreeBSD.org
+ Itsuro Saito saito@miv.t.u-tokyo.ac.jp
+ J. Bryant jbryant@argus.flash.net
+ J. David Lowe lowe@saturn5.com
+ J. Han hjh@best.com
+ J. Hawk jhawk@MIT.EDU
+ J.T. Conklin jtc@cygnus.com
+ J.T. Jang keith@email.gcn.net.tw
+ Jack jack@zeus.xtalwind.net
+ Jacob Bohn Lorensen jacob@jblhome.ping.mk
+ Jagane D Sundar jagane@netcom.com
+ Jake Hamby jehamby@lightside.com
+ James Clark jjc@jclark.com
+ James D. Stewart jds@c4systm.com
+ James Jegers jimj@miller.cs.uwm.edu
+ James Raynard fhackers@jraynard.demon.co.uk
+ James T. Liu jtliu@phlebas.rockefeller.edu
+ James da Silva jds@cs.umd.edu
+ Jan Conard charly@fachschaften.tu-muenchen.de
+ Jan Koum jkb@FreeBSD.org
+ Janick Taillandier Janick.Taillandier@ratp.fr
+ Janusz Kokot janek@gaja.ipan.lublin.pl
+ Jarle Greipsland jarle@idt.unit.no
+ Jason Garman init@risen.org
+ Jason Thorpe thorpej@NetBSD.org
+ Jason Wright jason@OpenBSD.org
+ Jason Young doogie@forbidden-donut.anet-stl.com
+ Javier Martin Rueda jmrueda@diatel.upm.es
+ Jay Fenlason hack@datacube.com
+ Jaye Mathisen mrcpu@cdsnet.net
+ Jeff Bartig jeffb@doit.wisc.edu
+ Jeff Forys jeff@forys.cranbury.nj.us
+ Jeff Kletsky Jeff@Wagsky.com
+ Jeffrey Evans evans@scnc.k12.mi.us
+ Jeffrey Wheat jeff@cetlink.net
+ Jens Schweikhardt schweikh@ito.uni-stuttgart.de
+ Jeremy Allison jallison@whistle.com
+ Jeremy Chatfield jdc@xinside.com
+ Jeremy Lea reg@shale.csir.co.za
+ Jeremy Prior
+ Jeroen Ruigrok/Asmodai asmodai@wxs.nl
+ Jesse Rosenstock jmr@ugcs.caltech.edu
+ Jian-Da Li jdli@csie.nctu.edu.tw
+ Jim Babb babb@FreeBSD.org
+ Jim Binkley jrb@cs.pdx.edu
+ Jim Carroll jim@carroll.com
+ Jim Flowers jflowers@ezo.net
+ Jim Leppek jleppek@harris.com
+ Jim Lowe james@cs.uwm.edu
+ Jim Mattson jmattson@sonic.net
+ Jim Mercer jim@komodo.reptiles.org
+ Jim Mock jim@phrantic.phear.net
+ Jim Wilson wilson@moria.cygnus.com
+ Jimbo Bahooli griffin@blackhole.iceworld.org
+ Jin Guojun jin@george.lbl.gov
+ Joachim Kuebart
+ Joao Carlos Mendes Luis jonny@jonny.eng.br
+ Jochen Pohl jpo.drs@sni.de
+ Joe "Marcus" Clarke marcus@miami.edu
+ Joe Abley jabley@clear.co.nz
+ Joe Jih-Shian Lu jslu@dns.ntu.edu.tw
+ Joe Orthoefer j_orthoefer@tia.net
+ Joe Traister traister@mojozone.org
+ Joel Faedi Joel.Faedi@esial.u-nancy.fr
+ Joel Ray Holveck joelh@gnu.org
+ Joel Sutton sutton@aardvark.apana.org.au
+ Johan Granlund johan@granlund.nu
+ Johan Karlsson k@numeri.campus.luth.se
+ Johan Larsson johan@moon.campus.luth.se
+ Johann Tonsing jtonsing@mikom.csir.co.za
+ Johannes Helander
+ Johannes Stille
+ John Baldwin jobaldwi@vt.edu
+ John Beckett jbeckett@southern.edu
+ John Beukema jbeukema@hk.super.net
+ John Brezak
+ John Capo jc@irbs.com
+ John F. Woods jfw@jfwhome.funhouse.com
+ John Goerzen jgoerzen@alexanderwohl.complete.org
+ John Hay jhay@mikom.csir.co.za
+ John Heidemann johnh@isi.edu
+ John Hood cgull@owl.org
+ John Kohl
+ John Lind john@starfire.mn.org
+ John Mackin john@physiol.su.oz.au
+ John P johnp@lodgenet.com
+ John Perry perry@vishnu.alias.net
+ John Preisler john@vapornet.com
+ John Rochester jr@cs.mun.ca
+ John Sadler john_sadler@alum.mit.edu
+ John Saunders john@pacer.nlc.net.au
+ John W. DeBoskey jwd@unx.sas.com
+ John Wehle john@feith.com
+ John Woods jfw@eddie.mit.edu
+ Jon Morgan morgan@terminus.trailblazer.com
+ Jonathan H N Chin jc254@newton.cam.ac.uk
+ Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca
+ Jorge Goncalves j@bug.fe.up.pt
+ Jorge M. Goncalves ee96199@tom.fe.up.pt
+ Jos Backus jbackus@plex.nl
+ Jose M. Alcaide jose@we.lc.ehu.es
+ Josef Grosch jgrosch@superior.mooseriver.com
+ Josef Karthauser joe@uk.freebsd.org
+ Joseph Stein joes@seaport.net
+ Josh Gilliam josh@quick.net
+ Josh Tiefenbach josh@ican.net
+ Juergen Lock nox@jelal.hb.north.de
+ Juha Inkari inkari@cc.hut.fi
+ Jukka A. Ukkonen jua@iki.fi
+ Julian Assange proff@suburbia.net
+ Julian Coleman j.d.coleman@ncl.ac.uk
+ Julian H. Stacey jhs@freebsd.org
+ Julian Jenkins kaveman@magna.com.au
+ Junichi Satoh junichi@jp.freebsd.org
+ Junji SAKAI sakai@jp.freebsd.org
+ Junya WATANABE junya-w@remus.dti.ne.jp
+ K.Higashino a00303@cc.hc.keio.ac.jp
+ KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
+ Kai Vorma vode@snakemail.hut.fi
+ Kaleb S. Keithley kaleb@ics.com
+ Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp
+ Kapil Chowksey kchowksey@hss.hns.com
+ Karl Denninger karl@mcs.com
+ Karl Dietz Karl.Dietz@triplan.com
+ Karl Lehenbauer karl@NeoSoft.com
+ Kato Takenori kato@eclogite.eps.nagoya-u.ac.jp
+ Kauzo Horikawa h-horik@yk.rim.or.jp
+ Kawanobe Koh kawanobe@st.rim.or.jp
+ Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp
+ Kazuo Horikawa horikawa@jp.FreeBSD.org
+ Kees Jan Koster kjk1@ukc.ac.uk
+ Keith Bostic bostic@bostic.com
+ Keith E. Walker
+ Keith Moore
+ Keith Sklower
+ Ken Hornstein
+ Ken Key key@cs.utk.edu
+ Ken Mayer kmayer@freegate.com
+ Kenji Saito marukun@mx2.nisiq.net
+ Kenji Tomita tommyk@da2.so-net.or.jp
+ Kenneth Furge kenneth.furge@us.endress.com
+ Kenneth Monville desmo@bandwidth.org
+ Kenneth R. Westerback krw@tcn.net
+ Kenneth Stailey kstailey@gnu.ai.mit.edu
+ Kent Talarico kent@shipwreck.tsoft.net
+ Kent Vander Velden graphix@iastate.edu
+ Kentaro Inagaki JBD01226@niftyserve.ne.jp
+ Kevin Bracey kbracey@art.acorn.co.uk
+ Kevin Day toasty@dragondata.com
+ Kevin Lahey kml@nas.nasa.gov
+ Kevin Street street@iname.com
+ Kevin Van Maren vanmaren@fast.cs.utah.edu
+ Kiroh HARADA kiroh@kh.rim.or.jp
+ Klaus Klein kleink@layla.inka.de
+ Klaus-J. Wolf Yanestra@t-online.de
+ Koichi Sato copan@ppp.fastnet.or.jp
+ Kostya Lukin lukin@okbmei.msk.su
+ Kouichi Hirabayashi kh@mogami-wire.co.jp
+ Kurt D. Zeilenga Kurt@Boolean.NET
+ Kurt Olsen kurto@tiny.mcs.usu.edu
+ L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu
+ Lars Köller Lars.Koeller@Uni-Bielefeld.DE
+ Larry Altneu larry@ALR.COM
+ Laurence Lopez lopez@mv.mv.com
+ Lee Cremeans lcremean@tidalwave.net
+ Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw
+ Lon Willett lon%softt.uucp@math.utah.edu
+ Louis A. Mamakos louie@TransSys.COM
+ Louis Mamakos loiue@TransSys.com
+ Lucas James Lucas.James@ldjpc.apana.org.au
+ Lyndon Nerenberg lyndon@orthanc.com
+ M.C. Wong
+ MANTANI Nobutaka nobutaka@nobutaka.com
+ MIHIRA Sanpei Yoshiro sanpei@sanpei.org
+ MITA Yoshio mita@jp.FreeBSD.ORG
+ MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp
+ MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp
+ Magnus Enbom dot@tinto.campus.luth.se
+ Mahesh Neelakanta mahesh@gcomm.com
+ Makoto MATSUSHITA matusita@jp.freebsd.org
+ Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp
+ Malte Lance malte.lance@gmx.net
+ Manu Iyengar iyengar@grunthos.pscwa.psca.com
+ Marc Frajola marc@dev.com
+ Marc Ramirez mrami@mramirez.sy.yale.edu
+ Marc Slemko marcs@znep.com
+ Marc van Kempen wmbfmk@urc.tue.nl
+ Marcel Moolenaar marcel@scc.nl
+ Mario Sergio Fujikawa Ferreira lioux@gns.com.br
+ Mark Andrews
+ Mark Cammidge mark@gmtunx.ee.uct.ac.za
+ Mark Diekhans markd@grizzly.com
+ Mark Huizer xaa@stack.nl
+ Mark J. Taylor mtaylor@cybernet.com
+ Mark Krentel krentel@rice.edu
+ Mark Mayo markm@vmunix.com
+ Mark Thompson thompson@tgsoft.com
+ Mark Tinguely tinguely@plains.nodak.edu
+ Mark Treacy
+ Mark Valentine mark@linus.demon.co.uk
+ Martin Birgmeier
+ Martin Ibert mib@ppe.bb-data.de
+ Martin Kammerhofer dada@sbox.tu-graz.ac.at
+ Martin Renters martin@tdc.on.ca
+ Martti Kuparinen erakupa@kk.etx.ericsson.se
+ Masachika ISHIZUKA ishizuka@isis.min.ntt.jp
+ Mas.TAKEMURA
+ Masafumi NAKANE max@wide.ad.jp
+ Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp
+ Masanobu Saitoh msaitoh@spa.is.uec.ac.jp
+ Masanori Kanaoka kana@saijo.mke.mei.co.jp
+ Masanori Kiriake seiken@ncs.co.jp
+ Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp
+ Mats Lofkvist mal@algonet.se
+ Matt Bartley mbartley@lear35.cytex.com
+ Matt Thomas matt@3am-software.com
+ Matt White mwhite+@CMU.EDU
+ Matthew C. Mead mmead@Glock.COM
+ Matthew Cashdollar mattc@rfcnet.com
+ Matthew Flatt mflatt@cs.rice.edu
+ Matthew Fuller fullermd@futuresouth.com
+ Matthew N. Dodd winter@jurai.net
+ Matthew Stein matt@bdd.net
+ Matthias Pfaller leo@dachau.marco.de
+ Matthias Scheler tron@netbsd.org
+ Mattias Gronlund Mattias.Gronlund@sa.erisoft.se
+ Mattias Pantzare pantzer@ludd.luth.se
+ Maurice Castro maurice@planet.serc.rmit.edu.au
+ Max Euston meuston@jmrodgers.com
+ Max Khon fjoe@husky.iclub.nsu.ru
+ Maxim Bolotin max@rsu.ru
+ Micha Class michael_class@hpbbse.bbn.hp.com
+ Michael Butler imb@scgt.oz.au
+ Michael Butschky butsch@computi.erols.com
+ Michael Clay mclay@weareb.org
+ Michael Elbel me@FreeBSD.ORG
+ Michael Galassi nerd@percival.rain.com
+ Michael Hancock michaelh@cet.co.jp
+ Michael Hohmuth hohmuth@inf.tu-dresden.de
+ Michael Perlman canuck@caam.rice.edu
+ Michael Petry petry@netwolf.NetMasters.com
+ Michael Reifenberger root@totum.plaut.de
+ Michael Searle searle@longacre.demon.co.uk
+ Michal Listos mcl@Amnesiac.123.org
+ Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp
+ Miguel Angel Sagreras msagre@cactus.fi.uba.ar
+ Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp
+ Mika Nystrom mika@cs.caltech.edu
+ Mikael Hybsch micke@dynas.se
+ Mikael Karpberg karpen@ocean.campus.luth.se
+ Mike Del repenting@hotmail.com
+ Mike Durian durian@plutotech.com
+ Mike Durkin mdurkin@tsoft.sf-bay.org
+ Mike E. Matsnev mike@azog.cs.msu.su
+ Mike Evans mevans@candle.com
+ Mike Grupenhoff kashmir@umiacs.umd.edu
+ Mike Hibler mike@marker.cs.utah.edu
+ Mike Karels
+ Mike McGaughey mmcg@cs.monash.edu.au
+ Mike Meyer mwm@shiva.the-park.com
+ Mike Mitchell mitchell@ref.tfs.com
+ Mike Murphy mrm@alpharel.com
+ Mike Peck mike@binghamton.edu
+ Mike Spengler mks@msc.edu
+ Mikhail A. Sokolov mishania@demos.su
+ Mikhail Teterin mi@aldan.ziplink.net
+ Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW
+ Mitsuru IWASAKI iwasaki@pc.jaring.my
+ Monte Mitzelfelt monte@gonefishing.org
+ Morgan Davis root@io.cts.com
+ Mostyn Lewis mostyn@mrl.com
+ Motoyuki Kasahara m-kasahr@sra.co.jp
+ Motoyuki Konno motoyuki@snipe.rim.or.jp
+ Munechika Sumikawa sumikawa@kame.net
+ Murray Stokely murray@cdrom.com
+ N.G.Smith ngs@sesame.hensa.ac.uk
+ NAGAO Tadaaki nagao@cs.titech.ac.jp
+ NAKAJI Hiroyuki nakaji@zeisei.dpri.kyoto-u.ac.jp
+ NAKAMURA Kazushi nkazushi@highway.or.jp
+ NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp
+ NIIMI Satoshi sa2c@and.or.jp
+ NOKUBI Hirotaka h-nokubi@yyy.or.jp
+ Nadav Eiron nadav@barcode.co.il
+ Nanbor Wang nw1@cs.wustl.edu
+ Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp
+ Naoki Hamada nao@tom-yam.or.jp
+ Narvi narvi@haldjas.folklore.ee
+ Nathan Dorfman nathan@rtfm.net
+ Neal Fachan kneel@ishiboo.com
+ Neil Blakey-Milner nbm@rucus.ru.ac.za
+ Niall Smart rotel@indigo.ie
+ Nick Barnes Nick.Barnes@pobox.com
+ Nick Handel nhandel@NeoSoft.com
+ Nick Hilliard nick@foobar.org
+ Nick Sayer nsayer@quack.kfu.com
+ Nick Williams njw@cs.city.ac.uk
+ Nickolay N. Dudorov nnd@itfs.nsk.su
+ Niklas Hallqvist niklas@filippa.appli.se
+ Nisha Talagala nisha@cs.berkeley.edu
+ ZW6T-KND@j.asahi-net.or.jp
+ adrian@virginia.edu
+ alex@elvisti.kiev.ua
+ anto@netscape.net
+ bobson@egg.ics.nitch.ac.jp
+ bovynf@awe.be
+ burg@is.ge.com
+ chris@gnome.co.uk
+ colsen@usa.net
+ coredump@nervosa.com
+ dannyman@arh0300.urh.uiuc.edu
+ davids@SECNET.COM
+ derek@free.org
+ devet@adv.IAEhv.nl
+ djv@bedford.net
+ dvv@sprint.net
+ enami@ba2.so-net.or.jp
+ flash@eru.tubank.msk.su
+ flash@hway.ru
+ fn@pain.csrv.uidaho.edu
+ gclarkii@netport.neosoft.com
+ gordon@sheaky.lonestar.org
+ graaf@iae.nl
+ greg@greg.rim.or.jp
+ grossman@cygnus.com
+ gusw@fub46.zedat.fu-berlin.de
+ hfir@math.rochester.edu
+ hnokubi@yyy.or.jp
+ iaint@css.tuu.utas.edu.au
+ invis@visi.com
+ ishisone@sra.co.jp
+ iverson@lionheart.com
+ jpt@magic.net
+ junker@jazz.snu.ac.kr
+ k-sugyou@ccs.mt.nec.co.jp
+ kenji@reseau.toyonaka.osaka.jp
+ kfurge@worldnet.att.net
+ lh@aus.org
+ lhecking@nmrc.ucc.ie
+ mrgreen@mame.mu.oz.au
+ nakagawa@jp.freebsd.org
+ ohki@gssm.otsuka.tsukuba.ac.jp
+ owaki@st.rim.or.jp
+ pechter@shell.monmouth.com
+ pete@pelican.pelican.com
+ pritc003@maroon.tc.umn.edu
+ risner@stdio.com
+ roman@rpd.univ.kiev.ua
+ root@ns2.redline.ru
+ root@uglabgw.ug.cs.sunysb.edu
+ stephen.ma@jtec.com.au
+ sumii@is.s.u-tokyo.ac.jp
+ takas-su@is.aist-nara.ac.jp
+ tamone@eig.unige.ch
+ tjevans@raleigh.ibm.com
+ tony-o@iij.ad.jp amurai@spec.co.jp
+ torii@tcd.hitachi.co.jp
+ uenami@imasy.or.jp
+ uhlar@netlab.sk
+ vode@hut.fi
+ wlloyd@mpd.ca
+ wlr@furball.wellsfargo.com
+ wmbfmk@urc.tue.nl
+ yamagata@nwgpc.kek.jp
+ ziggy@ryan.org
+ Nobuhiro Yasutomi nobu@psrc.isac.co.jp
+ Nobuyuki Koganemaru kogane@koganemaru.co.jp
+ Norio Suzuki nosuzuki@e-mail.ne.jp
+ Noritaka Ishizumi graphite@jp.FreeBSD.ORG
+ Noriyuki Soda soda@sra.co.jp
+ Olaf Wagner wagner@luthien.in-berlin.de
+ Oleg Sharoiko os@rsu.ru
+ Oliver Breuninger ob@seicom.NET
+ Oliver Friedrichs oliver@secnet.com
+ Oliver Fromme oliver.fromme@heim3.tu-clausthal.de
+ Oliver Laumann net@informatik.uni-bremen.de
+ Oliver Oberdorf oly@world.std.com
+ Olof Johansson offe@ludd.luth.se
+ Osokin Sergey aka oZZ ozz@freebsd.org.ru
+ Pace Willisson pace@blitz.com
+ Paco Rosich rosich@modico.eleinf.uv.es
+ Palle Girgensohn girgen@partitur.se
+ Parag Patel parag@cgt.com
+ Pascal Pederiva pascal@zuo.dec.com
+ Pasvorn Boonmark boonmark@juniper.net
+ Patrick Gardella patrick@cre8tivegroup.com
+ Patrick Hausen
+ Paul Antonov apg@demos.su
+ Paul F. Werkowski
+ Paul Fox pgf@foxharp.boston.ma.us
+ Paul Koch koch@thehub.com.au
+ Paul Kranenburg pk@NetBSD.org
+ Paul Mackerras paulus@cs.anu.edu.au
+ Paul Popelka paulp@uts.amdahl.com
+ Paul S. LaFollette, Jr.
+ Paul Saab paul@mu.org
+ Paul Sandys myj@nyct.net
+ Paul T. Root proot@horton.iaces.com
+ Paul Vixie paul@vix.com
+ Paulo Menezes paulo@isr.uc.pt
+ Paulo Menezes pm@dee.uc.pt
+ Pedro A M Vazquez vazquez@IQM.Unicamp.BR
+ Pedro Giffuni giffunip@asme.org
+ Pete Bentley pete@demon.net
+ Peter Childs pjchilds@imforei.apana.org.au
+ Peter Cornelius pc@inr.fzk.de
+ Peter Haight peterh@prognet.com
+ Peter Jeremy perer.jeremy@alcatel.com.au
+ Peter M. Chen pmchen@eecs.umich.edu
+ Peter Much peter@citylink.dinoex.sub.org
+ Peter Olsson
+ Peter Philipp pjp@bsd-daemon.net
+ Peter Stubbs PETERS@staidan.qld.edu.au
+ Phil Maker pjm@cs.ntu.edu.au
+ Phil Sutherland philsuth@mycroft.dialix.oz.au
+ Phil Taylor phil@zipmail.co.uk
+ Philip Musumeci philip@rmit.edu.au
+ Pierre Y. Dampure pierre.dampure@k2c.co.uk
+ Pius Fischer pius@ienet.com
+ Pomegranate daver@flag.blackened.net
+ Powerdog Industries kevin.ruddy@powerdog.com
+ R. Kym Horsell
+ Rajesh Vaidheeswarran rv@fore.com
+ Ralf Friedl friedl@informatik.uni-kl.de
+ Randal S. Masutani randal@comtest.com
+ Randall Hopper rhh@ct.picker.com
+ Randall W. Dean rwd@osf.org
+ Randy Bush rbush@bainbridge.verio.net
+ Reinier Bezuidenhout rbezuide@mikom.csir.co.za
+ Remy Card Remy.Card@masi.ibp.fr
+ Ricardas Cepas rch@richard.eu.org
+ Richard Henderson richard@atheist.tamu.edu
+ Richard Hwang rhwang@bigpanda.com
+ Richard J Kuhns rjk@watson.grauel.com
+ Richard M. Neswold rneswold@drmemory.fnal.gov
+ Richard Seaman, Jr. dick@tar.com
+ Richard Stallman rms@gnu.ai.mit.edu
+ Richard Straka straka@user1.inficad.com
+ Richard Tobin richard@cogsci.ed.ac.uk
+ Richard Wackerbarth rkw@Dataplex.NET
+ Richard Winkel rich@math.missouri.edu
+ Richard Wiwatowski rjwiwat@adelaide.on.net
+ Rick Macklem rick@snowhite.cis.uoguelph.ca
+ Rick Macklin
+ Rob Austein sra@epilogue.com
+ Rob Mallory rmallory@qualcomm.com
+ Rob Snow rsnow@txdirect.net
+ Robert Crowe bob@speakez.com
+ Robert D. Thrush rd@phoenix.aii.com
+ Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de
+ Robert Sanders rsanders@mindspring.com
+ Robert Sexton robert@kudra.com
+ Robert Shady rls@id.net
+ Robert Swindells swindellsr@genrad.co.uk
+ Robert Watson robert@cyrus.watson.org
+ Robert Withrow witr@rwwa.com
+ Robert Yoder
+ Robin Carey robin@mailgate.dtc.rankxerox.co.uk
+ Roger Hardiman roger@cs.strath.ac.uk
+ Roland Jesse jesse@cs.uni-magdeburg.de
+ Ron Bickers rbickers@intercenter.net
+ Ron Lenk rlenk@widget.xmission.com
+ Ronald Kuehn kuehn@rz.tu-clausthal.de
+ Rudolf Cejka
+ Ruslan Belkin rus@home2.UA.net
+ Ruslan Ermilov ru@ucb.crimea.ua
+ Ruslan Shevchenko rssh@cam.grad.kiev.ua
+ Russell L. Carter rcarter@pinyon.org
+ Russell Vincent rv@groa.uct.ac.za
+ Ryan Younce ryany@pobox.com
+ SANETO Takanori sanewo@strg.sony.co.jp
+ SAWADA Mizuki miz@qb3.so-net.ne.jp
+ SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
+ SURANYI Peter suranyip@jks.is.tsukuba.ac.jp
+ Sakari Jalovaara sja@tekla.fi
+ Sam Hartman hartmans@mit.edu
+ Samuel Lam skl@ScalableNetwork.com
+ Sander Vesik sander@haldjas.folklore.ee
+ Sandro Sigala ssigala@globalnet.it
+ Sascha Blank blank@fox.uni-trier.de
+ Sascha Wildner swildner@channelz.GUN.de
+ Satoh Junichi junichi@astec.co.jp
+ Satoshi Taoka taoka@infonets.hiroshima-u.ac.jp
+ Scot Elliott scot@poptart.org
+ Scot W. Hetzel hetzels@westbend.net
+ Scott A. Kenney saken@rmta.ml.org
+ Scott Blachowicz scott.blachowicz@seaslug.org
+ Scott Burris scott@pita.cns.ucla.edu
+ Scott Hazen Mueller scott@zorch.sf-bay.org
+ Scott Michel scottm@cs.ucla.edu
+ Scott Reynolds scott@clmqt.marquette.mi.us
+ Sebastian Strollo seb@erix.ericsson.se
+ Seigou TANIMURA tanimura@naklab.dnj.ynu.ac.jp
+ Serge A. Babkin babkin@hq.icb.chel.su
+ Serge V. Vakulenko vak@zebub.msk.su
+ Sergei Chechetkin csl@whale.sunbay.crimea.ua
+ Sergei S. Laskavy laskavy@pc759.cs.msu.su
+ Sergey Gershtein sg@mplik.ru
+ Sergey Potapov sp@alkor.ru
+ Sergey Shkonda serg@bcs.zp.ua
+ Sergey V.Dorokhov svd@kbtelecom.nalnet.ru
+ Sergio Lenzi lenzi@bsi.com.br
+ Shaun Courtney shaun@emma.eng.uct.ac.za
+ Shawn M. Carey smcarey@mailbox.syr.edu
+ Sheldon Hearn axl@iafrica.com
+ Shigio Yamaguchi shigio@wafu.netgate.net
+ Shunsuke Akiyama akiyama@jp.freebsd.org
+ Simon simon@masi.ibp.fr
+ Simon Burge simonb@telstra.com.au
+ Simon J Gerraty sjg@melb.bull.oz.au
+ Simon Marlow simonm@dcs.gla.ac.uk
+ Simon Shapiro shimon@simon-shapiro.org
+ Sin'ichiro MIYATANI siu@phaseone.co.jp
+ Slaven Rezic eserte@cs.tu-berlin.de
+ Soochon Radee slr@mitre.org
+ Soren Dayton csdayton@midway.uchicago.edu
+ Soren Dossing sauber@netcom.com
+ Soren S. Jorvang soren@dt.dk
+ Stefan Bethke stb@hanse.de
+ Stefan Eggers seggers@semyam.dinoco.de
+ Stefan Moeding s.moeding@ndh.net
+ Stefan Petri
+ Stefan `Sec` Zehl sec@42.org
+ Steinar Haug sthaug@nethelp.no
+ Stephane E. Potvin sepotvin@videotron.ca
+ Stephane Legrand stephane@lituus.fr
+ Stephen Clawson sclawson@marker.cs.utah.edu
+ Stephen F. Combs combssf@salem.ge.com
+ Stephen Farrell stephen@farrell.org
+ Stephen Hocking sysseh@devetir.qld.gov.au
+ Stephen J. Roznowski sjr@home.net
+ Stephen McKay syssgm@devetir.qld.gov.au
+ Stephen Melvin melvin@zytek.com
+ Steve Bauer sbauer@rock.sdsmt.edu
+ Steve Deering
+ Steve Gerakines steve2@genesis.tiac.net
+ Steve Gericke steveg@comtrol.com
+ Steve Piette steve@simon.chi.il.US
+ Steve Schwarz schwarz@alpharel.com
+ Steven G. Kargl kargl@troutmask.apl.washington.edu
+ Steven H. Samorodin samorodi@NUXI.com
+ Steven McCanne mccanne@cs.berkeley.edu
+ Steven Plite splite@purdue.edu
+ Steven Wallace
+ Stuart Henderson stuart@internationalschool.co.uk
+ Sue Blake sue@welearn.com.au
+ Sugiura Shiro ssugiura@duo.co.jp
+ Sujal Patel smpatel@wam.umd.edu
+ Sune Stjerneby stjerneby@usa.net
+ Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp
+ Tadashi Kumano kumano@strl.nhk.or.jp
+ Taguchi Takeshi taguchi@tohoku.iij.ad.jp
+ Takahashi Yoshihiro nyan@dd.catv.ne.jp
+ Takahiro Yugawa yugawa@orleans.rim.or.jp
+ Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp
+ Takashi Mega mega@minz.org
+ Takashi Uozu j1594016@ed.kagu.sut.ac.jp
+ Takayuki Ariga a00821@cc.hc.keio.ac.jp
+ Takeru NAIKI naiki@bfd.es.hokudai.ac.jp
+ Takeshi Amaike amaike@iri.co.jp
+ Takeshi MUTOH mutoh@info.nara-k.ac.jp
+ Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp
+ Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp
+ Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp
+ Tatoku Ogaito tacha@tera.fukui-med.ac.jp
+ Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org
+ Ted Buswell tbuswell@mediaone.net
+ Ted Faber faber@isi.edu
+ Ted Lemon
+ Terry Lambert terry@lambert.org
+ Terry Lee terry@uivlsi.csl.uiuc.edu
+ Tetsuya Furukawa tetsuya@secom-sis.co.jp
+ Theo de Raadt deraadt@OpenBSD.org
+ Thomas thomas@mathematik.uni-Bremen.de
+ Thomas D. Dean tomdean@ix.netcom.com
+ Thomas David Rivers rivers@dignus.com
+ Thomas G. McWilliams tgm@netcom.com
+ Thomas Gellekum thomas@ghpc8.ihf.rwth-aachen.de
+ Thomas Graichen graichen@omega.physik.fu-berlin.de
+ Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de
+ Thomas Ptacek
+ Thomas Stromberg tstrombe@rtci.com
+ Thomas Valentino Crimi tcrimi+@andrew.cmu.edu
+ Thomas Wintergerst thomas@lemur.nord.de
+ Þórður Ívarsson totii@est.is
+ Tim Kientzle kientzle@netcom.com
+ Tim Singletary tsingle@sunland.gsfc.nasa.gov
+ Tim Wilkinson tim@sarc.city.ac.uk
+ Timo J. Rinne tri@iki.fi
+ Todd Miller millert@openbsd.org
+ Tom root@majestix.cmr.no
+ Tom tom@sdf.com
+ Tom Gray - DCA dcasba@rain.org
+ Tom Hukins tom@eborcom.com
+ Tom Jobbins tom@tom.tj
+ Tom Pusateri pusateri@juniper.net
+ Tom Rush tarush@mindspring.com
+ Tom Samplonius tom@misery.sdf.com
+ Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp
+ Tony Kimball alk@Think.COM
+ Tony Li tli@jnx.com
+ Tony Lynn wing@cc.nsysu.edu.tw
+ Torbjorn Granlund tege@matematik.su.se
+ Toshihiko ARAI toshi@tenchi.ne.jp
+ Toshihiko SHIMOKAWA toshi@tea.forus.or.jp
+ Toshihiro Kanda candy@kgc.co.jp
+ Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp
+ Trefor S. trefor@flevel.co.uk
+ Trevor Blackwell tlb@viaweb.com
+ URATA Shuichiro s-urata@nmit.tmg.nec.co.jp
+ Ugo Paternostro paterno@dsi.unifi.it
+ Ulf Kieber kieber@sax.de
+ Ulli Linzen ulli@perceval.camelot.de
+ Ustimenko Semen semen@iclub.nsu.ru
+ Uwe Arndt arndt@mailhost.uni-koblenz.de
+ Vadim Chekan vadim@gc.lviv.ua
+ Vadim Kolontsov vadim@tversu.ac.ru
+ Vadim Mikhailov mvp@braz.ru
+ Van Jacobson van@ee.lbl.gov
+ Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru
+ Vasim Valejev vasim@uddias.diaspro.com
+ Vernon J. Schryver vjs@mica.denver.sgi.com
+ Vic Abell abe@cc.purdue.edu
+ Ville Eerola ve@sci.fi
+ Vincent Poy vince@venus.gaianet.net
+ Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de
+ Virgil Champlin champlin@pa.dec.com
+ Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua
+ Vladimir Kushnir kushn@mail.kar.net
+ Vsevolod Lobko seva@alex-ua.com
+ W. Gerald Hicks wghicks@bellsouth.net
+ W. Richard Stevens rstevens@noao.edu
+ Walt Howard howard@ee.utah.edu
+ Warren Toomey wkt@csadfa.cs.adfa.oz.au
+ Wayne Scott wscott@ichips.intel.com
+ Werner Griessl werner@btp1da.phy.uni-bayreuth.de
+ Wes Santee wsantee@wsantee.oz.net
+ Wietse Venema wietse@wzv.win.tue.nl
+ Wilfredo Sanchez wsanchez@apple.com
+ Wiljo Heinen wiljo@freeside.ki.open.de
+ Wilko Bulte wilko@yedi.iaf.nl
+ Willem Jan Withagen wjw@surf.IAE.nl
+ William Jolitz withheld
+ William Liao william@tale.net
+ Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl
+ Wolfgang Helbig helbig@ba-stuttgart.de
+ Wolfgang Solfrank ws@tools.de
+ Wolfgang Stanglmeier wolf@FreeBSD.org
+ Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW
+ Yarema yds@ingress.com
+ Yaroslav Terletsky ts@polynet.lviv.ua
+ Yen-Shuo Su yssu@CCCA.NCTU.edu.tw
+ Ying-Chieh Liao ijliao@csie.NCTU.edu.tw
+ Yixin Jin yjin@rain.cs.ucla.edu
+ Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp
+ Yoshihiko OHTA yohta@bres.tsukuba.ac.jp
+ Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp
+ Yoshikazu Goto gotoh@ae.anritsu.co.jp
+ Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp
+ Yoshishige Arai ryo2@on.rim.or.jp
+ Yuichi MATSUTAKA matutaka@osa.att.ne.jp
+ Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp
+ Yukihiro Nakai nacai@iname.com
+ Yusuke Nawano azuki@azkey.org
+ Yuval Yarom yval@cs.huji.ac.il
+ Yves Fonk yves@cpcoup5.tn.tudelft.nl
+ Yves Fonk yves@dutncp8.tn.tudelft.nl
+ Zach Heilig zach@gaffaneys.com
+ Zahemszhky Gabor zgabor@code.hu
+ Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw
+ arci vega@sophia.inria.fr
+ der Mouse mouse@Collatz.McRCIM.McGill.EDU
+ frf frf@xocolatl.com
+ Ege Rekk aagero@aage.priv.no
-
- Brandon Gillespie brandon@roguetrader.com
-
-
-
- &a.wlloyd;
-
-
-
- Bob Wilcox bob@obiwan.uucp
-
-
-
- Boyd Faulkner faulkner@mpd.tandem.com
-
-
-
- Brent J. Nordquist bjn@visi.com
-
-
-
- Brett Taylor brett@peloton.physics.montana.edu
-
-
-
- Brian Clapper bmc@willscreek.com
-
-
-
- Brian F. Feldman green@unixhelp.org
-
-
-
- Brian Handy handy@lambic.space.lockheed.com
-
-
-
- Brian Tao taob@risc.org
-
-
-
- Brion Moss brion@queeg.com
-
-
-
- Bruce Gingery bgingery@gtcs.com
-
-
-
- Bruce Mah bmah@ca.sandia.gov
-
-
-
- Carey Jones mcj@acquiesce.org
-
-
-
- Carl Fongheiser cmf@netins.net
-
-
-
- Charles Hannum mycroft@ai.mit.edu
-
-
-
- Charles Mott cmott@srv.net
-
-
-
- Chet Ramey chet@odin.INS.CWRU.Edu
-
-
-
- Chia-liang Kao clkao@CirX.ORG
-
-
-
- Chris Dabrowski chris@vader.org
-
-
-
- Chris G. Demetriou cgd@postgres.berkeley.edu
-
-
-
- Chris Shenton cshenton@angst.it.hq.nasa.gov
-
-
-
- Chris Stenton jacs@gnome.co.uk
-
-
-
- Chris Timmons skynyrd@opus.cts.cwu.edu
-
-
-
- Chris Torek torek@ee.lbl.gov
-
-
-
- Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at
-
-
-
- Christian Haury Christian.Haury@sagem.fr
-
-
-
- Christoph Robitschko chmr@edvz.tu-graz.ac.at
-
-
-
- Christopher T. Johnson
- cjohnson@neunacht.netgsi.com
-
-
-
- Choi Jun Ho junker@jazz.snu.ac.kr
-
-
-
- Chuck Hein chein@cisco.com
-
-
-
- Clive Lin clive@CiRX.ORG
-
-
-
- Conrad Sabatier conrads@neosoft.com
-
-
-
- Cornelis van der Laan nils@guru.ims.uni-stuttgart.de
-
-
-
- Craig Struble cstruble@vt.edu
-
-
-
- Cristian Ferretti cfs@riemann.mat.puc.cl
-
-
-
- Curt Mayer curt@toad.com
-
-
-
- Dai Ishijima ishijima@tri.pref.osaka.jp
-
-
-
- Dan Cross tenser@spitfire.ecsel.psu.edu
-
-
-
- Daniel Baker dbaker@crash.ops.neosoft.com
-
-
-
- Daniel M. Eischen deischen@iworks.InterWorks.org
-
-
-
- Daniel O'Connor doconnor@gsoft.com.au
-
-
-
- Danny J. Zerkel dzerkel@feephi.phofarm.com
-
-
-
- Dave Bodenstab imdave@synet.net
-
-
-
- Dave Burgess burgess@hrd769.brooks.af.mil
-
-
-
- Dave Chapeskie dchapes@ddm.on.ca
-
-
-
- Dave Edmondson davided@sco.com
-
-
-
- Dave Rivers rivers@ponds.uucp
-
-
-
- David A. Bader dbader@umiacs.umd.edu
-
-
-
- David Dawes dawes@physics.su.OZ.AU
-
-
-
- David Holloway daveh@gwythaint.tamis.com
-
-
-
- David Leonard d@scry.dstc.edu.au
-
-
-
- Dean Huxley dean@fsa.ca
-
-
-
- Dima Sivachenko demon@gpad.ac.ru
-
-
-
- Dirk Froemberg dirk@hal.in-berlin.de
-
-
-
- Dmitry Kohmanyuk dk@farm.org
-
-
-
- Dom Mitchell dom@myrddin.demon.co.uk
-
-
-
- Don Croyle croyle@gelemna.ft-wayne.in.us
-
-
-
- &a.whiteside;
-
-
-
- Don Yuniskis dgy@rtd.com
-
-
-
- Donald Maddox dmaddox@scsn.net
-
-
-
- Doug Ambrisko ambrisko@ambrisko.roble.com
-
-
-
- Douglas Carmichael dcarmich@mcs.com
-
-
-
- Eckart “Isegrim” Hofmann
- Isegrim@Wunder-Nett.org
-
-
-
- Eiji-usagi-MATSUmoto usagi@clave.gr.jp
-
-
-
- ELISA Font Project
-
-
-
- Eric A. Griff eagriff@global2000.net
-
-
-
- Eric Blood eblood@cs.unr.edu
-
-
-
- Eric J. Chet ejc@bazzle.com
-
-
-
- Eric J. Schwertfeger eric@cybernut.com
-
-
-
- Francis M J Hsieh mjhsieh@life.nthu.edu.tw
-
-
-
- Frank Bartels knarf@camelot.de
-
-
-
- Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw
-
-
-
- Frank Maclachlan fpm@crash.cts.com
-
-
-
- Frank Nobis fn@trinity.radio-do.de
-
-
-
- Frank Volf volf@oasis.IAEhv.nl
-
-
-
- FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp
-
-
-
- FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp
-
-
-
- Gary A. Browning gab10@griffcd.amdahl.com
-
-
-
- Gary Kline kline@thought.org
-
-
-
- Gerard Roudier groudier@club-internet.fr
-
-
-
- Gilad Rom rom_glsa@ein-hashofet.co.uk
-
-
-
- Ginga Kawaguti
- ginga@amalthea.phys.s.u-tokyo.ac.jp
-
-
-
- Glenn Johnson gljohns@bellsouth.net
-
-
-
- Greg Ungerer gerg@stallion.oz.au
-
-
-
- Hans Huebner hans@artcom.de
-
-
-
- Hans Petter Bieker hanspb@persbraten.vgs.no
-
-
-
- Harlan Stenn Harlan.Stenn@pfcs.com
-
-
-
- Havard Eidnes Havard.Eidnes@runit.sintef.no
-
-
-
- Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp
-
-
-
- Hidekazu Kuroki hidekazu@cs.titech.ac.jp
-
-
-
- Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp
-
-
-
- Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
-
-
-
- Hironori Ikura hikura@kaisei.org
-
-
-
- Hiroyuki NAKAJI nakaji@zeisei3.dpri.kyoto-u.ac.jp
-
-
-
- Holger Veit Holger.Veit@gmd.de
-
-
-
- HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp
-
-
-
- Horance Chou horance@freedom.ie.cycu.edu.tw
-
-
-
- Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw
-
-
-
- Ian Struble ian@broken.net
-
-
-
- Ian Vaudrey i.vaudrey@bigfoot.com
-
-
-
- Igor Vinokurov igor@zynaps.ru
-
-
-
- Ikuo Nakagawa ikuo@isl.intec.co.jp
-
-
-
- IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp
-
-
-
- Ishii Masahiro
-
-
-
- Iseei Suzuki issei@jp.FreeBSD.ORG
-
-
-
- Itsuro Saito saito@miv.t.u-tokyo.ac.jp
-
-
-
- J. David Lowe lowe@saturn5.com
-
-
-
- J. Han jtc@cygnus.com
-
-
-
- J.T. Conklin jtc@cygnus.com
-
-
-
- J.T. Lang keith@email.gcn.net.tw
-
-
-
- James Clark jjc@jclark.com
-
-
-
- James da Silva jds@cs.umd.edu et al
-
-
-
- Janusz Kokot janek@gaja.ipan.lublin.pl
-
-
-
- Jason Thorpe thorpej@nas.nasa.gov
-
-
-
- Javier Martin Rueda jmrueda@diatel.upm.es
-
-
-
- Jeff Bartig jeffb@doit.wisc.edu
-
-
-
- Keff Kletsky Jeff@Wagsky.com
-
-
-
- Jeffrey Wheat jeff@cetlink.net
-
-
-
- Jeremy Lea reg@shale.csir.co.za
-
-
-
- Jerry Hicks jhicks@glenatl.glenayre.com
-
-
-
- Jian-Da Li jdli@csie.NCTU.edu.tw
-
-
-
- Jim Binkley jrb@cs.pdx.edu
-
-
-
- Jim Lowe james@cs.uwm.edu
-
-
-
- Jim Mock jim@phrantic.phear.net
-
-
- Jim Wilson wilson@moria.cygnus.com
-
-
-
- Jimbo Bahooli
- griffin@blackhole.iceworld/org
-
-
-
- Joao Carlos Mendes Luis jonny@coppe.ufrj.br
-
-
-
- Joe Abley jabley@clear.co.nz
-
-
-
- Joe “Marcus” Clarke
- marcus@miami.edu
-
-
-
- Joe Jih-Shian Lu jslu@dns.ntu.edu.tw
-
-
-
- Joel Sutton sutton@aardvark.apana.org.au
-
-
-
- Johann Tonsing jtonsing@mikom.csir.co.za
-
-
-
- John Capo jc@irbs.com
-
-
-
- John Heidemann johnh@isi.edu
-
-
-
- John Hood cgull@owl.org
-
-
-
- John Perry perry@vishnu.alias.net
-
-
-
- John Polstra jdp@polstra.com
-
-
-
- John Rochester jr@cs.mun.ca
-
-
-
- John Saunders john@pacer.nlc.net.au
-
-
-
- Jonathan Hanna
- jh@pc-21490.bc.rogers.wave.ca
-
-
-
- Josef Karthauser joe@uk.freebsd.org
-
-
-
- Joseph Stein joes@seaport.net
-
-
-
- Josh Gilliam josh@quick.net
-
-
-
- Josh Tiefenbach josh@ican.net
-
-
-
- Juergen Lock nox@jelal.hb.north.de
-
-
-
- Juha Inkari inkari@cc.hut.fi
-
-
-
- Julian Assange proff@suburbia.net
-
-
-
- Julian Jenkins kaveman@magna.com.au
-
-
-
- Julian Stacey jhs@freebsd.org
-
-
-
- Junichi Satoh junichi@jp.freebsd.org
-
-
-
- Junya WATANABE junya-w@remus.dti.ne.jp
-
-
-
- Kapil Chowksey kchowksey@hss.hns.com
-
-
-
- Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp
-
-
-
- Keith Bostic bostic@bostic.com
-
-
-
- Keith Moore
-
-
-
- Kenneth Monville desmo@bandwidth.org
-
-
-
- Kent Vander Velden graphix@iastate.edu
-
-
-
- Kentaro Inagaki JBD01226@niftyserve.ne.jp
-
-
-
- Kirk McKusick mckusick@mckusick.com
-
-
-
- Kiroh HARADA kiroh@kh.rim.or.jp
-
-
-
- Koichi Sato copan@ppp.fastnet.or.jp
-
-
-
- Kostya Lukin lukin@okbmei.msk.su
-
-
-
- KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
-
-
-
- Kurt Olsen kurto@tiny.mcs.usu.edu
-
-
-
- Lars Köller Lars.Koeller@Uni-Bielefeld.DE
-
-
-
- Lian Tai-hwa
- avatar@www.mmlab.cse.yzu.edu.twu
-
-
-
- Lucas James Lucas.James@ldjpc.apana.org.au
-
-
-
- Luigi Rizzo luigi@iet.unipi.it
-
-
-
- Malte Lance malte.lance@gmx.net
-
-
-
- Makoto MATSUSHITA matusita@jp.freebsd.org
-
-
-
- Makoto WATANABE
- watanabe@zlab.phys.nagoya-u.ac.jp
-
-
-
- MANTANI Nobutaka nobutaka@nobutaka.com
-
-
-
- Manu Iyengar iyengar@grunthos.pscwa.psca.com
-
-
-
- Marc Frajola marc@dev.com
-
-
-
- Marc Ramirez mrami@mramirez.sy.yale.edu
-
-
-
- Marc Slemko marcs@znep.com
-
-
-
- Marc van Kempen wmbfmk@urc.tue.nl
-
-
-
- Mario Sergio Fujikawa Ferreira lioux@gns.com.br
-
-
-
- Mark Huizer xaa@stack.nl
-
-
-
- Mark J. Taylor mtaylor@cybernet.com
-
-
-
- Mark Krentel krentel@rice.edu
-
-
-
- Mark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.edu
-
-
-
- Martin Birgmeier
-
-
-
- Martti Kuparinen erakupa@kk.etx.ericsson.se
-
-
-
- Masachika ISHIZUKA ishizuka@isis.min.ntt.jp
-
-
-
- Masanori Kiriake seiken@ncs.co.jp
-
-
-
- Mats Lofkvist mal@algonet.se
-
-
-
- Matt Bartley mbartley@lear35.cytex.com
-
-
-
- Matt Thomas thomas@lkg.dec.com
-
-
-
- Matt White mwhite+@CMU.EDU
-
-
-
- Matthew N. Dodd winter@jurai.net
-
-
-
- Matthew Stein matt@bdd.net
-
-
-
- Maurice Castro maurice@planet.serc.rmit.edu.au
-
-
-
- Michael Butschky butsch@computi.erols.com
-
-
-
- Michael Elbel me@FreeBSD.ORG
-
-
-
- Michael Searle searle@longacre.demon.co.uk
-
-
-
- Miguel Angel Sagreras msagre@cactus.fi.uba.ar
-
-
-
- Mikael Hybsch micke@dynas.se
-
-
-
- Mikhail Teterin mi@aldan.ziplink.net
-
-
-
- Mike McGaughey mmcg@cs.monash.edu.au
-
-
-
- Mike Peck mike@binghamton.edu
-
-
-
- Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW
-
-
-
- MITA Yoshio mita@jp.FreeBSD.ORG
-
-
-
- MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp
-
-
-
- Motoyuki Kasahara m-hasahr@sra.co.jp
-
-
-
- Munechika Sumikawa sumikawa@kame.net
-
-
-
- Murray Stokely murray@cdrom.com
-
-
-
- NAKAMURA Kazushi nkazushi@highway.or.jp
-
-
-
- Naoki Hamada nao@tom-yam.or.jp
-
-
-
- Narvi narvi@haldjas.folklore.ee
-
-
-
- NIIMI Satoshi sa2c@and.or.jp
-
-
-
- Nick Sayer nsayer@quack.kfu.com
-
-
-
- Nicolas Souchu Nicolas.Souchu@prism.uvsq.fr
-
-
-
- Nisha Talagala nisha@cs.berkeley.edu
-
-
-
- Nobuhiro Yasutomi nobu@psrc.isac.co.jp
-
-
-
- Nobuyuki Koganemaru kogane@kces.koganemaru.co.jp
-
-
-
- Norio Suzuki nosuzuki@e-mail.ne.jp
-
-
-
- Noritaka Ishizumi graphite@jp.FreeBSD.ORG
-
-
-
- Oliver Breuninger ob@seicom.NET
-
-
-
- Oliver Fromme oliver.fromme@heim3.tu-clausthal.de
-
-
-
- Oliver Laumann net@informatik.uni-bremen.de
-
-
-
- Oliver Oberdorf oly@world.std.com
-
-
-
- Palle Girgensohn girgen@partitur.se
-
-
-
- Paul Fox pgf@foxharp.boston.ma.us
-
-
-
- Paul Kranenburg pk@cs.few.eur.nl
-
-
-
- Paul Mackerras paulus@cs.anu.edu.au
-
-
-
- Paulo Menezes paulo@isr.uc.pt
-
-
-
- Paul T. Root proot@horton.iaces.com
-
-
-
- Pedro Giffuni giffunip@asme.org
-
-
-
- Pedro A M Vazquez vazquez@IQM.Unicamp.BR
-
-
-
- Peter Cornelius pc@inr.fzk.de
-
-
-
- Peter Haight peterh@prognet.com
-
-
-
- Peter Stubbs PETERS@staidan.qld.edu.au
-
-
-
- Pierre Beyssac bp@fasterix.freenix.org
-
-
-
- Phil Maker pjm@cs.ntu.edu.au
-
-
-
- R. Kym Horsell
-
-
-
- Randall Hopper rhh@stealth.ct.picker.com
-
-
-
- Ricardas Cepas rch@richard.eu.org
-
-
-
- Richard Hwang rhwang@bigpanda.com
-
-
-
- Richard. M. Neswold rneswold@drmemory.fnal.gov
-
-
-
- Richard Seaman, Jr. dick@tar.com
-
-
-
- Richard Stallman rms@gnu.ai.mit.edu
-
-
-
- Richard Wiwatowski rjwiwat@adelaide.on.net
-
-
-
- Rob Mallory rmallory@csusb.edu
-
-
-
- Rob Shady rls@id.net
-
-
-
- Rob Snow rsnow@txdirect.net
-
-
-
- Robert Sanders rsanders@mindspring.com
-
-
-
- Robert Withrow witr@rwwa.com
-
-
-
- Ronald Kuehn kuehn@rz.tu-clausthal.de
-
-
-
- Roland Jesse jesse@cs.uni-magdeburg.de
-
-
-
- Ruslan Shevchenko rssh@cki.ipri.kiev.ua
-
-
-
- SURANYI Peter suranyip@jks.is.tsukuba.ac.jp
-
-
-
- Samuel Lam skl@ScalableNetwork.com
-
-
-
- Sander Vesik sander@haldjas.folklore.ee
-
-
-
- Sandro Sigala ssigala@globalnet.it
-
-
-
- Sascha Blank blank@fox.uni-trier.de
-
-
-
- Sascha Wildner swildner@channelz.GUN.de
-
-
-
- Satoshi Taoka taoka@infonets.hiroshima-u.ac.jp
-
-
-
- Satsuki FUJISHIMA k5@respo.or.jp
-
-
-
- Scot W. Hetzel hetzels@westbend.net
-
-
-
- Scott Blachowicz scott.blachowicz@seaslug.org
-
-
-
- Scott A. Kenney saken@rmta.ml.org
-
-
-
- Seigou TANIMURA
- tanimura@naklab.dnj.ynu.ac.jp
-
-
-
- Serge Babkin babkin@hq.icb.chel.su
-
-
-
- Serge V. Vakulenko vak@zebub.msk.su
-
-
-
- Sheldon Hearn axl@iafrica.com
-
-
-
- Shigeyuki FUKUSHIMA
- shige@kuis.kyoto-u.ac.jp
-
-
-
- Simon Marlow simonm@dcs.gla.ac.uk
-
-
-
- Slaven Rezic (Tomic) eserte@cs.tu-berlin.de
-
-
-
- Soren Dayton csdayton@midway.uchicago.edu
-
-
-
- Soren Dossing sauber@netcom.com
-
-
-
- Stefan Eggers seggers@semyam.dinoco.de
-
-
-
- Stefan Moeding s.moeding@ndh.net
-
-
-
- Stefan “Sec” Zehl sec@42.org
-
-
-
- Stephane Legrand stephane@lituus.fr
-
-
-
- Stephen Farrell stephen@farrell.org
-
-
-
- Stephen J. Roznowski sjr@home.net
-
-
-
- Steve Gerakines steve2@genesis.tiac.net
-
-
-
- Steven G. Kargl
- kargl@troutmask.apl.washington.edu
-
-
-
- Stephen H. Samorodin samorodi@NUXU.com
-
-
-
- Stuart Henderson
- stuart@internationalschool.co.uk
-
-
-
- SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
-
-
-
- Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp
-
-
-
- Tadashi Kumano kumano@strl.nhk.or.jp
-
-
-
- Taguchi Takeshi taguchi@tohoku.iij.ad.jp
-
-
-
- Takashi Mega mega@minz.org
-
-
-
- Takashi Uozu j1594016@ed.kagu.sut.ac.jp
-
-
-
- Takayuki Ariga a00821@cc.hc.keio.ac.jp
-
-
-
- Takeu NAIKI naiki@bfd.es.hokudai.ac.jp
-
-
-
- Ted Faber faber@ISI.EDU
-
-
-
- Terry Lambert terry@lambert.org
-
-
-
- Terry Lee terry@uivlsi.csl.uiuc.edu
-
-
-
- Tetsuya Furukawa tetsuya@secom-sis.co.jp
-
-
-
- Theo Deraadt deraadt@fsa.ca
-
-
-
- Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de
-
-
-
- Þórður Ívarsson totii@est.is
-
-
-
- Tim Kientzle kientzle@netcom.com
-
-
-
- Tim Wilkinson tim@sarc.city.ac.uk
-
-
-
- Tom Hukins tom@eborcom.com
-
-
-
- Tom Jobbins tom@tom.tj
-
-
-
- Tom Samplonius tom@misery.sdf.com
-
-
-
- Torbjorn Granlund tege@matematik.su.se
-
-
-
- Toshihiro Kanda candy@fct.kgc.co.jp
-
-
-
- Toshihiko SHIMOKAWA toshi@tea.forus.or.jp
-
-
-
- Trefor S. trefor@flevel.co.uk
-
-
-
- Vadim Chekan vadim@gc.lviv.ua
-
-
-
- Ville Eerola ve@sci.fi
-
-
-
- Vladimir Kushnir kushn@mail.kar.net
-
-
-
- Werner Griessl werner@btp1da.phy.uni-bayreuth.de
-
-
-
- Wes Santee wsantee@wsantee.oz.net
-
-
-
- Wilko Bulte wilko@yedi.iaf.nl
-
-
-
- Wolfgang Stanglmeier wolf@kintaro.cologne.de
-
-
-
- Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW
-
-
-
- Yen-Shuo Su yssu@CCCA.NCTU.edu.tw
-
-
-
- Ying-Chieh Liao ijliao@csie.NCTU.edu.tw
-
-
-
- Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp
-
-
-
- Yoshiro Mihira sanpei@yy.cs.keio.ac.jp
-
-
-
- Yukihiro Nakai nakai@iname.com
-
-
-
- Yusuke Nawano azuki@azkey.org
-
-
-
- Yuval Yarom yval@cs.huji.ac.il
-
-
-
- Yves Fonk yves@cpcoup5.tn.tudelft.nl
- 386BSD 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 e06beb5775..a97ada4bd4 100644
--- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
@@ -1,2528 +1,2542 @@
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 <emphasis>not</emphasis>?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
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 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
&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. For a fairly easy interface to this, simply type:
+ 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
+ &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgzUse 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.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.
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/&rel.current;-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.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
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.
+ url="ftp://releng3.FreeBSD.org/pub/FreeBSD/">ftp://releng3.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;
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/stable-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 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.tgz
+ &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/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;<anchor id="anoncvs-intro">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.<anchor id="anoncvs-usage">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:/cvs
+ anoncvs@anoncvs.FreeBSD.org:/cvs
Since 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_3The 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
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 (<citerefentry>
<refentrytitle>ls</refentrytitle>
<manvolnum>1</manvolnum></citerefentry>) 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 <citerefentry>
<refentrytitle>ls</refentrytitle>
<manvolnum>1</manvolnum></citerefentry> 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
+ url="http://www.FreeBSD.org/cgi/cvsweb.cgi">CVSWeb
is the FreeBSD Project web interface for CVS.<application>CTM</application>Contributed 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 <application>CTM</application>?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 <application>CTM</application>?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 <application>CTM</application> 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 <application>CTM</application> 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 <application>CTM</application> 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 <application>CTM</application>Tons 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...<application>CVSup</application>Contributed 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.
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/ports-current/net/cvsup.tar">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
+ cannot use the binary package versions due to the fact that they
+ require 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.
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/ports-current/net/cvsup.tar">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.
+ URL="http://www.research.digital.com/SRC/modula-3/html/home.html">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).
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup-bin-16.0.tar.gz">ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup-bin-16.0.tar.gz (client including GUI).
ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.4.2.tar.gz (client without GUI).
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-16.0.tar.gz">ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-16.0.tar.gz (client without GUI).
ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupd-bin-15.4.2.tar.gz (server).
+ URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupd-bin-16.0.tar.gz">ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupd-bin-16.0.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).
+ URL="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/CVSup/cvsup-bin-15.3.tar.gz">ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/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).
+ URL="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-15.3.tar.gz">ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/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).
+ URL="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/CVSup/cvsupd-bin-15.3.tar.gz">ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/development/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.
+ URL="file:/usr/share/examples/cvsup">/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.RELENG_3The 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
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_8_RELEASE
+
+
+ FreeBSD-2.2.8. 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:
+ one that is close to you in cyberspace. In this example we
+will use a fictional FreeBSD distribution site, cvsup666.FreeBSD.org:
-*default host=cvsup.FreeBSD.org
+*default host=cvsup666.FreeBSD.org
- On any particular run of cvsup, you can override this
+ You will need to change the host to one that actually
+exists before running CVSup. On any particular run of
+cvsup, you can override the host
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 host=cvsup666.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress
src-all
cvs-cryptoRunning <application>CVSup</application>You 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.<application>CVSup</application> 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 Reports
-
+ For more information
+
+ For the CVSup FAQ and other information about CVSup, see
+The CVSup Home
+Page.
+
Most 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 <command>make world</command> 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 93d21fbb15..5346c92816 100644
--- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
@@ -1,1289 +1,1294 @@
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-currentfreebsd-ispIssues for Internet Service Providers using
FreeBSDfreebsd-jobsFreeBSD employment and consulting
opportunitiesfreebsd-newbiesNew FreeBSD users activities and discussionsfreebsd-questionsUser questions and technical supportfreebsd-stableDiscussion concerning the use of
FreeBSD-stableTechnical 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-docCreating 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-DOCDocumentation projectThis 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-STABLEDiscussions about the use of
FreeBSD-stableThis 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/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.bg.freebsd.org/ — Bulgaria.http://www.ca.freebsd.org/ — Canada/1.http://freebsd.kawartha.com/ — Canada/2.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.is.freebsd.org/ — Iceland.http://www.ie.freebsd.org/ — Ireland.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.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://www4.ru.freebsd.org/ — Russia/4.
+
+
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.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://www6.freebsd.org/ — USA/Oregon.http://www2.freebsd.org/ — USA/Texas.
diff --git a/en_US.ISO8859-1/books/handbook/install/chapter.sgml b/en_US.ISO8859-1/books/handbook/install/chapter.sgml
index e058416801..e26e9dcf6e 100644
--- a/en_US.ISO8859-1/books/handbook/install/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/install/chapter.sgml
@@ -1,1232 +1,1207 @@
Installing FreeBSDSo, you would like to try out FreeBSD on your system? This section
is a quick-start guide for what you need to do. FreeBSD can be
installed from a variety of media including CD-ROM, floppy disk,
magnetic tape, an MS-DOS partition and, if you have a network
connection, via anonymous ftp or NFS.Regardless of the installation media you choose, you can get
started by creating the installation
- disk as described below. Booting your computer into the
+ disks as described below. Booting your computer into the
FreeBSD installer, even if you aren't planning on installing FreeBSD
right away, will provide important information about compatibility
between FreeBSD and your hardware which may, in turn, dictate which
installation options are even possible. It can also provide early
clues to any compatibility problems which could prevent FreeBSD
running on your system at all.If you plan on installing via
- anonymous FTP then this installation floppy is all you need to
+ anonymous FTP then the installation floppies are all you need to
download and create—the installation program itself will handle
any further required downloading directly (using an ethernet connection,
a modem and ppp dialip #, etc).For more information on obtaining the latest FreeBSD
distributions, please see Obtaining
FreeBSD in the
Appendix.So, to get the show on the road, follow these steps:Review the supported
configurations section of this installation guide to be sure
that your hardware is supported by FreeBSD. It may be helpful
to make a list of any special cards you have installed, such as
SCSI controllers, Ethernet adapters or sound cards. This list
should include relevant configuration parameters such as
interrupts (IRQ) and IO port addresses.If you're installing FreeBSD from CDROM media then you have
several different installation options:If the CD has been mastered with El Torrito boot
support and your system supports direct booting from CDROM
(and many older systems do not),
simply insert the CD into the drive and boot directly from
it.If you're running DOS and have the proper drivers to
access your CD, run the install.bat script provided on the
CD. This will attempt to boot into the FreeBSD
installation straight from DOS.You must do this from actual DOS and not a Windows
DOS box.If you also want to install FreeBSD
from your DOS partition (perhaps because your CDROM drive
is completely unsupported by FreeBSD) then run the setup
program first to copy the appropriate files from the CD to
your DOS partition, afterwards running install.If either of the two proceeding methods work then you
can simply skip the rest of this section, otherwise your
- final option is to create a boot floppy from the
- floppies\boot.flp image—proceed to
+ final option is to create a set of boot floppies from the
+ floppies\kern.flp and
+ floppies\mfsroot.flp images—proceed to
step 4 for instructions on how to do this.
- If you don't have a CDROM distribution then simply download
- the installation boot disk image file to your hard drive, being sure to tell your browser to save rather than display the file.
-
-
- This disk image can only be used with 1.44 megabyte 3.5
- inch floppy disks.
-
+ If you don't have a CDROM distribution then simply read the
+ installation boot image information to find out what files you need to download first.
- Make the installation boot disk from the image file:
+ Make the installation boot disks from the image files:If you are using MS-DOS then download fdimage.exe or get it from tools\fdimage.exe on the CDROM and then run it like so:
- E:\>tools\fdimage floppies\boot.flp a:
+ E:\>tools\fdimage floppies\kern.flp a:The fdimage
program will format the A: drive and then copy the
- boot.flp image onto it (assuming that you're at the top
+ kern.flp image onto it (assuming that you're at the top
level of a FreeBSD distribution and the floppy images live
- in the floppies subdirectory, as is typically the
+ in the floppies subdirectory, as is typically the
case).If you are using a UNIX system to create the floppy
- image:
+ images:
- &prompt.root; dd if=boot.flp of=disk_device
+ &prompt.root; dd if=kern.flp of=disk_devicedisk_device is
the /dev entry for the floppy drive.
On FreeBSD systems, this is /dev/rfd0
for the A: drive and /dev/rfd1 for
the B: drive.
- With the installation disk in the A: drive, reboot your
- computer. You should get a boot prompt something like this:
-
-
->> FreeBSD BOOT ...
-Usage: [[[0:][wd](0,a)]/kernel][-abcCdhrsv]
-Use 1:sd(0,a)kernel to boot sd0 if it is BIOS drive 1
-Use ? for file list or press Enter for defaults
-Boot:
-
-
- If you do not type
- anything, FreeBSD will automatically boot with its default
+ With the kern.flp in the A: drive, reboot your
+ computer. The next request you should get is for the
+ mfsroot.flp floppy, after which the
+ installation will proceed normally.
+
+ If you do not type anything at the boot
+ prompt which appears during this process, FreeBSD will
+ automatically boot with its default
configuration after a delay of about five seconds. As FreeBSD
boots, it probes your computer to determine what hardware is
installed. The results of this probing is displayed on the
screen.When the booting process is finished, The main FreeBSD
installation menu will be displayed.
- If something goes wrong...
+ If something goes wrong…Due to limitations of the PC architecture, it is impossible for
probing to be 100 percent reliable. In the event that your hardware
is incorrectly identified, or that the probing causes your computer to
lock up, first check the
supported configurations
section of this installation guide to be sure that your hardware is
indeed supported by FreeBSD.If your hardware is supported, reset the computer and when the
- Boot: prompt comes up, type
- -c. This puts FreeBSD into a configuration mode
+ visual kernel configuration choice is presented, take it.
+ This puts FreeBSD into a configuration mode
where you can supply hints about your hardware. The FreeBSD kernel on
the installation disk is configured assuming that most hardware
devices are in their factory default configuration in terms of IRQs,
IO addresses and DMA channels. If your hardware has been
- reconfigured, you will most likely need to use the
- option at boot to tell FreeBSD where things are.
+ reconfigured, you will most likely need to use the configuration
+ editor to tell FreeBSD where things are.
It is also possible that a probe for a device not present will
cause a later probe for another device that is present to fail. In
that case, the probes for the conflicting driver(s) should be
disabled.Do not disable any device you will need during installation, such
- as your screen (sc0).
+ as your screen (sc0). If the installation
+ wedges or fails mysteriously after leaving the configuration editor,
+ you have probably removed or changed something that you should not
+ have. Simply reboot and try again.
In the configuration mode, you can:List the device drivers installed in the kernel.Disable device drivers for hardware not present in your
system.Change the IRQ, DRQ, and IO port addresses used by a device
driver.
- While at the config> prompt, type
- help for more information on the
- available commands. After adjusting the kernel to match how you have
- your hardware configured, type quit at
- the config> prompt to continue
- booting with the new settings.
-
+ After adjusting the kernel to match how you have your hardware
+ configured, type Q to continue booting with the new
+ settings.
+
After FreeBSD has been installed, changes made in the
configuration mode will be permanent so you do not have to reconfigure
every time you boot. Even so, it is likely that you will want to
build a custom kernel to optimize the performance of your system. See
Kernel configuration for more information on creating
custom kernels.Supported ConfigurationsFreeBSD currently runs on a wide variety of ISA, VLB, EISA and
PCI bus based PC's, ranging from 386sx to Pentium class machines
(though the 386sx is not recommended). Support for generic IDE or
ESDI drive configurations, various SCSI controller, network and
serial cards is also provided.A minimum of four megabytes of RAM is required to run FreeBSD.
To run the X Window System, eight megabytes of RAM is the
recommended minimum.Following is a list of all disk controllers and Ethernet cards
currently known to work with FreeBSD. Other configurations may very
well work, and we have simply not received any indication of
this.Disk ControllersWD1003 (any generic MFM/RLL)WD1007 (any generic IDE/ESDI)IDEATAAdaptec 1505 ISA SCSI controllerAdaptec 152x series ISA SCSI controllersAdaptec 1535 ISA SCSI controllersAdaptec 154x series ISA SCSI controllersAdaptec 174x series EISA SCSI controller in standard and
enhanced mode.Adaptec 274x/284x/2940/2940U/3940 (Narrow/Wide/Twin)
series EISA/VLB/PCI SCSI controllers
- Adaptec AIC7850 on-board SCSI controllers
+ Adaptec AIC7850, 7890, 7891, 7895, 7896, and 7897
+ on-board SCSI controllersAdaptec AIC-6360 based boards, which includes the
AHA-152x and SoundBlaster SCSI cards.You cannot boot from the
SoundBlaster cards as they have no on-board BIOS, which is
necessary for mapping the boot device into the system BIOS
I/O vectors. They are perfectly usable for external tapes,
CDROMs, etc, however. The same goes for any other AIC-6x60
based card without a boot ROM. Some systems DO have a boot
ROM, which is generally indicated by some sort of message
when the system is first powered up or reset. Check your
system/board documentation for more details.Buslogic 545S & 545cBuslogic was formerly known as “Bustek”.Buslogic 445S/445c VLB SCSI controllerBuslogic 742A/747S/747c EISA SCSI controller.Buslogic 946c PCI SCSI controllerBuslogic 956c PCI SCSI controllerNCR 53C810/53C815/53C825/53C860/53C875 PCI SCSI
controller.NCR5380/NCR53400 (“ProAudio Spectrum”) SCSI
controller.DTC 3290 EISA SCSI controller in 1542 emulation mode.UltraStor 14F/24F/34F SCSI controllers.Seagate ST01/02 SCSI controllers.Future Domain 8xx/950 series SCSI controllers.WD7000 SCSI controllers.With all supported SCSI controllers, full support is provided
for SCSI-I & SCSI-II peripherals, including Disks, tape drives
(including DAT) and CD ROM drives.The following CD-ROM type systems are supported at this
time:SoundBlaster SCSI and ProAudio Spectrum SCSI (cd)Mitsumi (all models) proprietary interface (mcd)Matsushita/Panasonic (Creative) CR-562/CR-563
proprietary interface (matcd)Sony proprietary interface (scd)ATAPI IDE interface (experimental and should be
considered ALPHA quality!) (wcd)Ethernet cardsAllied-Telesis AT1700 and RE2000 cardsSMC Elite 16 WD8013 Ethernet interface, and most other
WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and
WD8013EBT based clones. SMC Elite Ultra and 9432TX based
cards are also supported.DEC EtherWORKS III NICs (DE203, DE204, and DE205)DEC EtherWORKS II NICs (DE200, DE201, DE202, and
DE422)DEC DC21040/DC21041/DC21140 based NICs:ASUS PCI-L101-TBAccton ENI1203Cogent EM960PCICompex CPXPCI/32CD-Link DE-530DEC DE435Danpex EN-9400P3JCIS Condor JC1260Kingston KNE100TXLinksys EtherPCIMylex LNP101SMC EtherPower 10/100 (Model 9332)SMC EtherPower (Model 8432)SMC EtherPower (2)Zynx ZX314Zynx ZX342DEC FDDI (DEFPA/DEFEA) NICsFujitsu FMV-181 and FMV-182Fujitsu MB86960A/MB86965AIntel EtherExpressIntel EtherExpress Pro/100B 100Mbit.Isolan AT 4141-0 (16 bit)Isolink 4110 (8 bit)Lucent WaveLAN wireless networking interface.Novell NE1000, NE2000, and NE2100 ethernet interface.3Com 3C501 cards3Com 3C503 Etherlink II3Com 3c505 Etherlink/+3Com 3C507 Etherlink 16/TP3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III3Com 3C590, 3C595 Etherlink III3Com 3C90x cards.HP PC Lan Plus (27247B and 27252A)Toshiba ethernet cardsPCMCIA ethernet cards from IBM and National
Semiconductor are also supported.FreeBSD does not currently support
PnP (plug-n-play) features present on some ethernet cards. If
your card has PnP and is giving you problems, try disabling its
PnP features.Miscellaneous devicesAST 4 port serial card using shared IRQ.ARNET 8 port serial card using shared IRQ.BOCA IOAT66 6 port serial card using shared IRQ.BOCA 2016 16 port serial card using shared IRQ.Cyclades Cyclom-y Serial Board.STB 4 port card using shared IRQ.SDL Communications Riscom/8 Serial Board.SDL Communications RISCom/N2 and N2pci sync serial
cards.Digiboard Sync/570i high-speed sync serial card.Decision-Computer Intl. “Eight-Serial” 8 port serial
cards using shared IRQ.Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum,
Gravis UltraSound, Gravis UltraSound MAX and Roland MPU-401
sound cards.Matrox Meteor video frame grabber.Creative Labs Video spigot frame grabber.Omnimedia Talisman frame grabber.Brooktree BT848 chip based frame grabbers.X-10 power controllers.PC joystick and speaker.FreeBSD does not currently support IBM's microchannel (MCA)
bus.Preparing for the InstallationThere are a number of different methods by which FreeBSD can be
installed. The following describes what preparation needs to be
done for each type.Before installing from CDROMIf your CDROM is of an unsupported type, then please skip to
MS-DOS
Preparation.There is not a lot of preparatory work that needs to be done
to successfully install from one of Walnut Creek's FreeBSD CDROMs
(other CDROM distributions may work as well, though we cannot say
for certain as we have no hand or say in how they are created).
You can either boot into the CD installation directly from DOS
- using Walnut Creek's supplied install.bat batch file or you
- can make a boot floppy with the makeflp.bat command.
+ using Walnut Creek's supplied install.bat batch file or you
+ can make boot floppies with the makeflp.bat command.
-
- If you are running FreeBSD 2.1-RELEASE and have an IDE
- CDROM, use the inst_ide.bat or atapiflp.bat batch files
- instead.
-
-
For the easiest interface of all (from DOS), type view.
This will bring up a DOS menu utility that leads you through all
the available options.
- If you are creating the boot floppy from a UNIX machine, see
+ If you are creating the boot floppies from a UNIX machine, see
the beginning of this
- guide for examples. of how to create the boot floppy.
+ guide for examples. of how to create the boot floppies.Once you have booted from DOS or floppy, you should then be
able to select CDROM as the media type in the Media menu and load
the entire distribution from CDROM. No other types of
installation media should be required.After your system is fully installed and you have rebooted
from the hard disk, you can mount the CDROM at any time by typing:
mount /cdromBefore removing the CD again, also note that it is necessary
to first type: umount /cdrom. Do not just
remove it from the drive!Before invoking the installation, be sure that the CDROM is
in the drive so that the install probe can find it. This is
also true if you wish the CDROM to be added to the default
system configuration automatically during the install (whether
or not you actually use it as the installation media).Finally, if you would like people to be able to FTP install
FreeBSD directly from the CDROM in your machine, you will find it
quite easy. After the machine is fully installed, you simply need
to add the following line to the password file (using the vipw
command):
ftp:*:99:99::0:0:FTP:/cdrom:/nonexistentAnyone with network connectivity to your machine (and
permission to log into it) can now chose a Media type of FTP and
type in: ftp://your
machine after picking “Other” in
the ftp sites menu.Before installing from FloppyIf you must install from floppy disks, either due to
unsupported hardware or simply because you enjoy doing things the
hard way, you must first prepare some floppies for the
install.You will need, at minimum, as many 1.44MB or 1.2MB floppies as
it takes to hold all files in the bin (binary distribution)
directory. If you are preparing these floppies under DOS, then
THESE floppies must be formatted using the MS-DOS FORMAT
command. If you are using Windows, use the Windows File Manager
format command.Do not trust Factory Preformatted
floppies! Format them again yourself, just to make sure. Many
problems reported by our users in the past have resulted from the
use of improperly formatted media, which is why I am taking such
special care to mention it here!If you are creating the floppies from another FreeBSD machine,
a format is still not a bad idea though you do not need to put a
DOS filesystem on each floppy. You can use the disklabel and
newfs commands to put a UFS filesystem on them instead, as the
following sequence of commands (for a 3.5" 1.44MB floppy disk)
illustrates:&prompt.root; fdformat -f 1440 fd0.1440
&prompt.root; disklabel -w -r fd0.1440 floppy3
&prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0Use fd0.1200 and
floppy5 for 5.25" 1.2MB disks.Then you can mount and write to them like any other file
system.After you have formatted the floppies, you will need to copy
the files onto them. The distribution files are split into chunks
conveniently sized so that 5 of them will fit on a conventional
1.44MB floppy. Go through all your floppies, packing as many
files as will fit on each one, until you have got all the
distributions you want packed up in this fashion. Each
distribution should go into a subdirectory on the floppy, e.g.:
a:\bin\bin.aa,
a:\bin\bin.ab, and so on.Once you come to the Media screen of the install, select
“Floppy” and you will be prompted for the rest.Before installing from a MS-DOS partitionTo prepare for installation from an MS-DOS partition, copy the
files from the distribution into a directory called
C:\FREEBSD. The directory tree structure of
the CDROM must be partially reproduced within this directory so we
suggest using the DOS xcopy command.
For example, to prepare for a minimal installation of FreeBSD:C:\>MD C:\FREEBSDC:\>XCOPY /S E:\BIN C:\FREEBSD\BIN\C:\>XCOPY /S E:\MANPAGES C:\FREEBSD\MANPAGES\Assuming that C:
is where you have free space and E:
is where your CDROM is mounted.For as many DISTS you wish to install from MS-DOS (and you
have free space for), install each one under
C:\FREEBSD — the BIN dist
is only the minimal requirement.Before installing from QIC/SCSI TapeInstalling from tape is probably the easiest method, short of
an on-line install using FTP or a CDROM install. The installation
program expects the files to be simply tar'ed onto the tape, so
after getting all of the files for distribution you are interested
in, simply tar them onto the tape with a command like:&prompt.root; cd /freebsd/distdir
&prompt.root; tar cvf /dev/rwt0 dist1 ... dist2When you go to do the installation, you should also make sure
that you leave enough room in some temporary directory (which you
will be allowed to choose) to accommodate the full contents of the tape you have created.
Due to the non-random access nature of tapes, this method of
installation requires quite a bit of temporary storage. You
should expect to require as much temporary storage as you have
stuff written on tape.When going to do the installation, the tape must be in the
drive before booting from the boot floppy.
The installation probe may otherwise fail to find it.Before installing over a networkYou can do network installations over 3 types of
communications links:Serial portSLIP or PPPParallel portPLIP (laplink cable)EthernetA standard ethernet controller (includes some
PCMCIA).SLIP support is rather primitive, and limited primarily to
hard-wired links, such as a serial cable running between a laptop
computer and another computer. The link should be hard-wired as
the SLIP installation does not currently offer a dialing
capability; that facility is provided with the PPP utility, which
should be used in preference to SLIP whenever possible.If you are using a modem, then PPP is almost certainly your
only choice. Make sure that you have your service provider's
information handy as you will need to know it fairly soon in the
installation process. You will need to know how to dial your ISP
using the “AT commands” specific to your modem, as the PPP
dialer provides only a very simple terminal emulator. If you're
using PAP or CHAP, you'll need to type the necessary set
authname and set authkey commands before typing term.
Refer to the user-ppp handbook
and FAQ entries for
further information. If you have problems, logging can be
directed to the screen using the command set
log local ....If a hard-wired connection to another FreeBSD (2.0R or later)
machine is available, you might also consider installing over a
“laplink” parallel port cable. The data rate over the parallel
port is much higher than what is typically possible over a serial
line (up to 50k/sec), thus resulting in a quicker
installation.Finally, for the fastest possible network installation, an
ethernet adaptor is always a good choice! FreeBSD supports most
common PC ethernet cards, a table of supported cards (and their
required settings) is provided in Supported
Hardware. If you are using one of the supported PCMCIA
ethernet cards, also be sure that it is plugged in
before the laptop is powered on! FreeBSD
does not, unfortunately, currently support hot insertion of PCMCIA
cards during installation.You will also need to know your IP address on the network, the
netmask value for your address class, and the name of your
machine. Your system administrator can tell you which values to
use for your particular network setup. If you will be referring
to other hosts by name rather than IP address, you will also need
a name server and possibly the address of a gateway (if you are
using PPP, it is your provider's IP address) to use in talking to
it. If you do not know the answers to all or most of these
questions, then you should really probably talk to your system
administrator first before trying this type
of installation.Once you have a network link of some sort working, the
installation can continue over NFS or FTP.Preparing for NFS installationNFS installation is fairly straight-forward: Simply copy the
FreeBSD distribution files you want onto a server somewhere and
then point the NFS media selection at it.If this server supports only “privileged port” access (as
is generally the default for Sun workstations), you will need to
set this option in the Options menu before installation can
proceed.If you have a poor quality ethernet card which suffers from
very slow transfer rates, you may also wish to toggle the
appropriate Options flag.In order for NFS installation to work, the server must
support subdir mounts, e.g., if your FreeBSD &rel.current;
distribution directory lives on:
ziggy:/usr/archive/stuff/FreeBSD Then ziggy
will have to allow the direct mounting of
/usr/archive/stuff/FreeBSD, not just
/usr or
/usr/archive/stuff.In FreeBSD's /etc/exports file, this is
controlled by the option. Other
NFS servers may have different conventions. If you are getting
Permission Denied messages from the server then it is likely
that you do not have this enabled properly.Preparing for FTP InstallationFTP installation may be done from any mirror site containing
a reasonably up-to-date version of FreeBSD &rel.current;. A
full menu of reasonable choices from almost anywhere in the
world is provided by the FTP site menu.If you are installing from some other FTP site not listed in
this menu, or you are having troubles getting your name server
configured properly, you can also specify your own URL by
selecting the “Other” choice in that menu. A URL can also be
a direct IP address, so the following would work in the absence
of a name server:ftp://165.113.121.81/pub/FreeBSD/&rel.current;-RELEASEThere are two FTP installation modes you can use:FTP ActiveFor all FTP transfers, use “Active” mode. This
will not work through firewalls, but will often work
with older ftp servers that do not support passive mode.
If your connection hangs with passive mode (the
default), try active!FTP PassiveFor all FTP transfers, use “Passive” mode. This
allows the user to pass through firewalls that do not
allow incoming connections on random port
addresses.Active and passive modes are not the same as a “proxy”
connection, where a proxy FTP server is listening and
forwarding FTP requests!For a proxy FTP server, you should usually give name of the
server you really want as a part of the username, after an
@-sign. The proxy server then 'fakes' the real server. An
example: Say you want to install from ftp.freebsd.org, using the
proxy FTP server foo.bar.com, listening on port 1234.In this case, you go to the options menu, set the FTP
username to ftp@ftp.freebsd.org, and the password to your e-mail
address. As your installation media, you specify FTP (or
passive FTP, if the proxy support it), and the URL
ftp://foo.bar.com:1234/pub/FreeBSD
/pub/FreeBSD from
ftp.freebsd.org is proxied
under foo.bar.com, allowing you to install from that machine
(which fetch the files from ftp.freebsd.org as your installation
requests them).Installing FreeBSDOnce you have taken note of the appropriate preinstallation
steps, you should be able to install FreeBSD without any further
trouble.Should this not be true, then you may wish to go back and
re-read the relevant preparation section above for the installation
media type you are trying to use, perhaps there is a helpful hint
there that you missed the first time? If you are having hardware
trouble, or FreeBSD refuses to boot at all, read the Hardware Guide
provided on the boot floppy for a list of possible solutions.
- The FreeBSD boot floppy contains all the on-line documentation
+ The FreeBSD boot floppies contain all the on-line documentation
you should need to be able to navigate through an installation and
if it does not then we would like to know what you found most
confusing. Send your comments to the &a.doc;. It is the objective
of the FreeBSD installation program (sysinstall) to be
self-documenting enough that painful “step-by-step” guides are no
longer necessary. It may take us a little while to reach that
objective, but that is the objective!Meanwhile, you may also find the following “typical
installation sequence” to be helpful:
- Boot the boot floppy. After a boot sequence which can
+ Boot the kern.flp floppy and, when
+ asked, remove it and insert the
+ mfsroot.flp floppy and hit return.. After a boot sequence which can
take anywhere from 30 seconds to 3 minutes, depending on your
hardware, you should be presented with a menu of initial
- choices. If the floppy does not boot at all, or the boot
+ choices. If the kern.flp floppy does not boot at all, or the boot
hangs at some stage, go read the Q&A section of the
Hardware Guide for possible causes.Press F1. You should see some basic usage instructions on
the menu system and general navigation. If you have not used
this menu system before then please read this thoroughly!Select the Options item and set any special preferences
you may have.Select a Novice, Custom or Express install, depending on
whether or not you would like the installation to help you
through a typical installation, give you a high degree of
control over each step of the installation or simply whizz
through it (using reasonable defaults when possible) as fast
as possible. If you have never used FreeBSD before then the
Novice installation method is most recommended.The final configuration menu choice allows you to further
configure your FreeBSD installation by giving you menu-driven
access to various system defaults. Some items, like
networking, may be especially important if you did a
CDROM/Tape/Floppy installation and have not yet configured
your network interfaces (assuming you have any). Properly
configuring such interfaces here will allow FreeBSD to come up
on the network when you first reboot from the hard
disk.MS-DOS User's Questions and AnswersMany FreeBSD users wish to install FreeBSD on PCs inhabited by
MS-DOS. Here are some commonly asked questions about installing
FreeBSD on such systems.Help! I have no space! Do I need to delete
everything first?If your machine is already running MS-DOS and has little or no
free space available for FreeBSD's installation, all is not lost!
You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or on the
various FreeBSD ftp sites, to be quite useful.FIPS allows you to split an existing MS-DOS partition into two
pieces, preserving the original partition and allowing you to
install onto the second free piece. You first defragment your
MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton
Disk tools, then run FIPS. It will prompt you for the rest of the
information it needs. Afterwards, you can reboot and install
FreeBSD on the new free slice. See the
Distributions menu for an estimation of how
much free space you will need for the kind of installation you
want.Can I use compressed MS-DOS filesystems from
FreeBSD?No. If you are using a utility such as Stacker(tm) or
DoubleSpace(tm), FreeBSD will only be able to use whatever portion
of the filesystem you leave uncompressed. The rest of the
filesystem will show up as one large file (the stacked/dblspaced
file!). Do not remove that file! You
will probably regret it greatly!It is probably better to create another uncompressed MS-DOS
primary partition and use this for communications between MS-DOS and
FreeBSD.Can I mount my MS-DOS extended
partitions?Yes. DOS extended partitions are mapped in at the end of the
other “slices” in FreeBSD, e.g. your D: drive might be /dev/sd0s5,
your E: drive /dev/sd0s6, and so on. This example assumes, of
course, that your extended partition is on SCSI drive 0. For IDE
drives, substitute wd for sd appropriately. You otherwise
mount extended partitions exactly like you would mount any other DOS
drive, e.g.:&prompt.root; mount -t msdos /dev/sd0s5 /dos_d
-
-
- Can I run MS-DOS binaries under
- FreeBSD?
-
- BSDI has donated their DOS emulator to the BSD world and this
- has been ported to FreeBSD.
-
- There is also a (technically) nice application available in the
- The Ports Collection called pcemu
- which allows you to run many basic MS-DOS text-mode binaries by
- entirely emulating an 8088 CPU.
-
diff --git a/en_US.ISO8859-1/books/handbook/mailing-lists.ent b/en_US.ISO8859-1/books/handbook/mailing-lists.ent
index 224f586b93..3e9e85fe41 100644
--- a/en_US.ISO8859-1/books/handbook/mailing-lists.ent
+++ b/en_US.ISO8859-1/books/handbook/mailing-lists.ent
@@ -1,48 +1,104 @@
+freebsd-advocacy@FreeBSD.ORG">
+
freebsd-announce@FreeBSD.ORG">
-cvs-all@FreeBSD.ORG">
-
-freebsd-doc@FreeBSD.ORG">
-
freebsd-bugs@FreeBSD.ORG">
+freebsd-chat@FreeBSD.ORG">
+
+freebsd-core@FreeBSD.ORG">
+
freebsd-current@FreeBSD.ORG">
+cvs-all@FreeBSD.ORG">
+
+freebsd-database@FreeBSD.ORG">
+
+freebsd-doc@FreeBSD.ORG">
+
freebsd-emulation@FreeBSD.ORG">
freebsd-fs@FreeBSD.ORG">
freebsd-hackers@FreeBSD.ORG">
+freebsd-hardware@FreeBSD.ORG">
+
+freebsd-isdn@FreeBSD.ORG">
+
+freebsd-isp@FreeBSD.ORG">
+
+freebsd-java@FreeBSD.ORG">
+
+freebsd-jobs@FreeBSD.ORG">
+
+freebsd-mobile@FreeBSD.ORG">
+
+freebsd-mozilla@FreeBSD.ORG">
+
+freebsd-multimedia@FreeBSD.ORG">
+
+freebsd-net@FreeBSD.ORG">
+
+freebsd-newbies@FreeBSD.ORG">
+
+new-bus-arch@bostonradio.org">
+
freebsd-ports@FreeBSD.ORG">
freebsd-questions@FreeBSD.ORG">
freebsd-scsi@FreeBSD.ORG">
+freebsd-security@FreeBSD.ORG">
+
+freebsd-security-notifications@FreeBSD.ORG">
+
+freebsd-small@FreeBSD.ORG">
+
+freebsd-smp@FreeBSD.ORG">
+
freebsd-stable@FreeBSD.ORG">
-majordomo@FreeBSD.ORG">
-
-freebsd-core@FreeBSD.ORG">
+freebsd-tokenring@FreeBSD.ORG">
+majordomo@FreeBSD.ORG">
diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
index 5f1a569539..d47e578e4e 100644
--- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
@@ -1,1443 +1,1481 @@
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:
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,
+ Spain,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
- Ukraine,
UK,
+ Ukraine,
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/FreeBSDFrance
-
+
+ In case of problems, please contact the hostmaster
+ hostmaster@fr.FreeBSD.ORG for this
+ domain.
+
-
ftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.
+ URL="ftp://ftp.fr.FreeBSD.ORG/pub/FreeBSD">ftp://ftp.fr.FreeBSD.ORG/pub/FreeBSD
-
+
+
+ ftp://ftp2.fr.FreeBSD.ORG/pub/FreeBSD
+
+
+
+
+
+ ftp://ftp3.fr.FreeBSD.ORG/pub/FreeBSD
+
+ 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/FreeBSD
-
-
-
+
+
+ ftp://ftp6.kr.FreeBSD.ORG/pub/FreeBSD
+
+
+
NetherlandsIn 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: 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/CTM
+ URL="ftp://ftp.freebsd.org/pub/FreeBSD/development/CTM">ftp://ftp.freebsd.org/pub/FreeBSD/development/CTM
Germany, 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)Canada
- cvsup.ca.FreeBSD.ORG (maintainer james@ican.net)
+ cvsup.ca.FreeBSD.ORG (maintainer dm@glbalserve.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)
-
+
+
+ cvsup2.ru.FreeBSD.ORG (maintainer
+ dv@dv.ru)
+ 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)Ukrainecvsup2.ua.FreeBSD.ORG (maintainer freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer joe@pavilion.net)USA
- cvsup.FreeBSD.ORG (maintainer skynyrd@opus.cts.cwu.edu)
+ cvsup1.FreeBSD.ORG (maintainer
+ skynyrd@opus.cts.cwu.edu),
+ Washington state
- cvsup2.FreeBSD.ORG (maintainer jdp@FreeBSD.ORG)
+ cvsup2.FreeBSD.ORG (maintainer
+ jdp@FreeBSD.ORG), California
- cvsup3.FreeBSD.ORG (maintainer wollman@FreeBSD.ORG)
+ cvsup3.FreeBSD.ORG (maintainer
+ wollman@FreeBSD.ORG),
+ Massachusetts
- cvsup4.FreeBSD.ORG (maintainer shmit@rcn.com)
+ cvsup4.FreeBSD.ORG (maintainer
+ shmit@rcn.com), Virginia
+
+
+ cvsup5.FreeBSD.ORG (maintainer
+ cvsup@adsu.bellsouth.com),
+ Georgia
+ 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;Sweden
-
+
+ The path to the files are:
+ /afs/stacken.kth.se/ftp/pub/FreeBSD
+
stacken.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/newsgroups.ent b/en_US.ISO_8859-1/books/handbook/newsgroups.ent
new file mode 100644
index 0000000000..0c1a8b9821
--- /dev/null
+++ b/en_US.ISO_8859-1/books/handbook/newsgroups.ent
@@ -0,0 +1,10 @@
+
+
+comp.unix.bsd.freebsd.misc
+ newsgroup">
+
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 2712be81df..35e532e05b 100644
--- a/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/ports/chapter.sgml
@@ -1,4672 +1,4674 @@
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 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= /tmpSubstitute /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/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/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.<filename>Makefile</filename>The 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 <filename>files</filename> 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 <filename>patches</filename> directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The <filename>pkg</filename> 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
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/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 <filename>Makefile</filename>The 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.<filename>COMMENT</filename>This 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.<filename>DESCR</filename>This 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
+ It is recommended that you sign your 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.edu<filename>PLIST</filename>This 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 <command>portlint</command>Please 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/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.
+ 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 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 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/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 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.<makevar>DISTNAME</makevar>You 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.<makevar>PKGNAME</makevar>If 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.<makevar>CATEGORIES</makevar>When 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!<makevar>MASTER_SITES</makevar>Record 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.<makevar>PATCHFILES</makevar>If 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 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.<makevar>MAINTAINER</makevar>Set 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.<makevar>LIB_DEPENDS</makevar>This 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.<makevar>RUN_DEPENDS</makevar>This 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.<makevar>BUILD_DEPENDS</makevar>This 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_TARGET<makevar>FETCH_DEPENDS</makevar>This 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.<makevar>DEPENDS</makevar>If 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
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.<command>ldconfig</command>If 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 shortly after 3.0-release,
+ 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
+ system can run as both ELF and a.out, and we wish to unofficially
+ support the 2.2 as long as possible. 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
+ The move-aout-libs target in the 3.0-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.<makevar>PORTOBJFORMAT</makevar>bsd.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
+ aout in 2.2-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.<makevar>LIB_DEPENDS</makevar>All 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.<filename>PLIST</filename>PLIST 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.<literal>ldconfig</literal>The 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.<makevar>MASTERDIR</makevar>If 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).<makevar>REQUIRES_MOTIF</makevar>If 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.<makevar>MOTIFLIB</makevar>This 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 <filename>pkg/</filename> subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.<filename>MESSAGE</filename>If 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.<filename>INSTALL</filename>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 from your port's
Makefile.<filename>REQ</filename>If 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 <filename>PLIST</filename> 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
<filename>pkg</filename> subdirectoryAll 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.VariableDefault valueCOMMENT${PKGDIR}/DESCRDESCR${PKGDIR}/DESCRPLIST${PKGDIR}/PLISTPKGINSTALL${PKGDIR}/PKGINSTALLPKGDEINSTALL${PKGDIR}/PKGDEINSTALLPKGREQ${PKGDIR}/REQPKGMESSAGE${PKGDIR}/MESSAGEPlease 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 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
+ ports/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.
-
+
+ Once again, please use
+ diff1 and not shar1 to send updates to ports.<anchor id="porting-dads">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.<makevar>WRKDIR</makevar>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.<makevar>WRKDIRPREFIX</makevar>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 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 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-RELEASE119411
- 2.1-currents
+ 2.1-CURRENTs199501, 1995032.0.5-RELEASE199504
- 2.2-current before 2.1
+ 2.2-CURRENT before 2.11995082.1.0-RELEASE199511
- 2.2-current before 2.1.5
+ 2.2-CURRENT before 2.1.51995122.1.5-RELEASE199607
- 2.2-current before 2.1.6
+ 2.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-RELEASE228001
- 3.0-current before mount(2) change
+ 3.0-CURRENT before mount(2) change300000
- 3.0-current after mount(2) change
+ 3.0-CURRENT after mount(2) change300001
- 3.0-current after semctl(2) change
+ 3.0-CURRENT after semctl(2) change300002
- 3.0-current after ioctl arg changes
+ 3.0-CURRENT after ioctl arg changes300003
- 3.0-current after ELF conversion
+ 3.0-CURRENT after ELF conversion3000043.0-RELEASE300005
- 3.0-current after 3.0-RELEASE
+ 3.0-CURRENT after 3.0-RELEASE300006
- 3.0-stable after 3/4 branch
+ 3.0-STABLE after 3/4 branch3000073.1-RELEASE310000
- 3.1-stable after 3.1-RELEASE
+ 3.1-STABLE after 3.1-RELEASE310001
- 4.0-current after 3/4 branch
+ 4.0-CURRENT after 3/4 branch400000Note 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
+ you don't have to worry about old -CURRENTs; 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
<filename>bsd.port.mk</filename>Do 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).<makevar>DIST_SUBDIR</makevar>Do 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.<makevar>PREFIX</makevar>Do 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 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 <makevar>CFLAGS</makevar>The 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 <filename>Makefile</filename>Here 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).CategoryDescriptionafterstep*Ports to support AfterStep window managerarchiversArchiving 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.palmSoftware support for the 3Com Palm(tm) series.perl5*Ports that require perl version 5 to run.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
managerwwwSoftware 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/staff/chapter.sgml b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
index 85ff0bc7b4..9f530dabbb 100644
--- a/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
@@ -1,838 +1,842 @@
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.shige;
+
+
&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.guido;
+
+
&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.comGallery 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;
+ &a.imp;>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 2712be81df..35e532e05b 100644
--- a/en_US.ISO_8859-1/books/porters-handbook/book.sgml
+++ b/en_US.ISO_8859-1/books/porters-handbook/book.sgml
@@ -1,4672 +1,4674 @@
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 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= /tmpSubstitute /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/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/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.<filename>Makefile</filename>The 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 <filename>files</filename> 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 <filename>patches</filename> directoryThis directory contains the patches needed to make everything work properly under
FreeBSD.The <filename>pkg</filename> 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
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/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 <filename>Makefile</filename>The 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.<filename>COMMENT</filename>This 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.<filename>DESCR</filename>This 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
+ It is recommended that you sign your 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.edu<filename>PLIST</filename>This 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 <command>portlint</command>Please 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/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.
+ 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 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 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/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 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.<makevar>DISTNAME</makevar>You 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.<makevar>PKGNAME</makevar>If 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.<makevar>CATEGORIES</makevar>When 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!<makevar>MASTER_SITES</makevar>Record 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.<makevar>PATCHFILES</makevar>If 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 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.<makevar>MAINTAINER</makevar>Set 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.<makevar>LIB_DEPENDS</makevar>This 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.<makevar>RUN_DEPENDS</makevar>This 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.<makevar>BUILD_DEPENDS</makevar>This 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_TARGET<makevar>FETCH_DEPENDS</makevar>This 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.<makevar>DEPENDS</makevar>If 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
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.<command>ldconfig</command>If 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 shortly after 3.0-release,
+ 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
+ system can run as both ELF and a.out, and we wish to unofficially
+ support the 2.2 as long as possible. 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
+ The move-aout-libs target in the 3.0-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.<makevar>PORTOBJFORMAT</makevar>bsd.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
+ aout in 2.2-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.<makevar>LIB_DEPENDS</makevar>All 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.<filename>PLIST</filename>PLIST 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.<literal>ldconfig</literal>The 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.<makevar>MASTERDIR</makevar>If 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).<makevar>REQUIRES_MOTIF</makevar>If 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.<makevar>MOTIFLIB</makevar>This 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 <filename>pkg/</filename> subdirectoryThere are some tricks we haven't mentioned yet about the
pkg/ subdirectory that come in handy
sometimes.<filename>MESSAGE</filename>If 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.<filename>INSTALL</filename>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 from your port's
Makefile.<filename>REQ</filename>If 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 <filename>PLIST</filename> 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
<filename>pkg</filename> subdirectoryAll 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.VariableDefault valueCOMMENT${PKGDIR}/DESCRDESCR${PKGDIR}/DESCRPLIST${PKGDIR}/PLISTPKGINSTALL${PKGDIR}/PKGINSTALLPKGDEINSTALL${PKGDIR}/PKGDEINSTALLPKGREQ${PKGDIR}/REQPKGMESSAGE${PKGDIR}/MESSAGEPlease 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 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
+ ports/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.
-
+
+ Once again, please use
+ diff1 and not shar1 to send updates to ports.<anchor id="porting-dads">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.<makevar>WRKDIR</makevar>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.<makevar>WRKDIRPREFIX</makevar>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 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 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-RELEASE119411
- 2.1-currents
+ 2.1-CURRENTs199501, 1995032.0.5-RELEASE199504
- 2.2-current before 2.1
+ 2.2-CURRENT before 2.11995082.1.0-RELEASE199511
- 2.2-current before 2.1.5
+ 2.2-CURRENT before 2.1.51995122.1.5-RELEASE199607
- 2.2-current before 2.1.6
+ 2.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-RELEASE228001
- 3.0-current before mount(2) change
+ 3.0-CURRENT before mount(2) change300000
- 3.0-current after mount(2) change
+ 3.0-CURRENT after mount(2) change300001
- 3.0-current after semctl(2) change
+ 3.0-CURRENT after semctl(2) change300002
- 3.0-current after ioctl arg changes
+ 3.0-CURRENT after ioctl arg changes300003
- 3.0-current after ELF conversion
+ 3.0-CURRENT after ELF conversion3000043.0-RELEASE300005
- 3.0-current after 3.0-RELEASE
+ 3.0-CURRENT after 3.0-RELEASE300006
- 3.0-stable after 3/4 branch
+ 3.0-STABLE after 3/4 branch3000073.1-RELEASE310000
- 3.1-stable after 3.1-RELEASE
+ 3.1-STABLE after 3.1-RELEASE310001
- 4.0-current after 3/4 branch
+ 4.0-CURRENT after 3/4 branch400000Note 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
+ you don't have to worry about old -CURRENTs; 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
<filename>bsd.port.mk</filename>Do 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).<makevar>DIST_SUBDIR</makevar>Do 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.<makevar>PREFIX</makevar>Do 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 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 <makevar>CFLAGS</makevar>The 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 <filename>Makefile</filename>Here 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).CategoryDescriptionafterstep*Ports to support AfterStep window managerarchiversArchiving 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.palmSoftware support for the 3Com Palm(tm) series.perl5*Ports that require perl version 5 to run.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
managerwwwSoftware 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!
:)