os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en/handbook/contrib/chapter.sgml
Nik Clayton 6ff34ef882 Replace 
<xref linkend="target" remap="foo">

with

    <link linkend="target">foo</link>

Internal links within the Handbook now do the right thing.
1998-11-05 23:28:48 +00:00

4915 lines
165 KiB
Text
Raw Blame History

<chapter id="contrib">
<title>Contributing to FreeBSD</title>
<para><emphasis>Contributed by &a.jkh;.</emphasis></para>
<para>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
<emphasis>relies</emphasis> 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!</para>
<para>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.</para>
<para>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 <filename>TODO</filename> 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!</para>
<para>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.</para>
<sect1>
<title>What Is Needed</title>
<para>The following list of tasks and sub-projects represents
something of an amalgam of the various core team <filename>TODO</filename> 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?</para>
<sect2>
<title>High priority tasks</title>
<para>The following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:</para>
<orderedlist>
<listitem>
<para>3-stage boot issues. Overall coordination:
&a.hackers;</para>
<itemizedlist>
<listitem>
<para>Autodetect memory over 64MB properly.</para>
</listitem>
<listitem>
<para>Move userconfig (-c) into 3rd stage boot.</para>
</listitem>
<listitem>
<para>Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Filesystem problems. Overall coordination: &a.fs;</para>
<itemizedlist>
<listitem>
<para>Fix the MSDOS file system.</para>
</listitem>
<listitem>
<para>Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;</para>
</listitem>
<listitem>
<para>Fix the union file system. Coordinator:
&a.dyson;</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Implement kernel and user vm86 support. Coordinator:
&a.hackers;</para>
</listitem>
<listitem>
<para>Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;</para>
</listitem>
<listitem>
<para>SCSI driver issues. Overall coordination:
&a.hackers;</para>
<itemizedlist>
<listitem>
<para>Support tagged queuing generically. Requires a
rewrite of how we do our command queuing, but we need
this anyway to for prioritized I/O (CD-R
writers/scanners).</para>
</listitem>
<listitem>
<para>Better error handling (Busy status and
retries).</para>
</listitem>
<listitem>
<para>Merged Scatter-Gather list creation code.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Kernel issues. Overall coordination: &a.hackers;</para>
<itemizedlist>
<listitem>
<para>Complete the eisaconf conversion of all existing
drivers.</para>
</listitem>
<listitem>
<para>Change all interrupt routines to take a (void *)
instead of using unit numbers.</para>
</listitem>
<listitem>
<para>Merge EISA/PCI/ISA interrupt registration
code.</para>
</listitem>
<listitem>
<para>Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)</para>
</listitem>
<listitem>
<para>Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;</para>
</listitem>
<listitem>
<para>Rewrite the Intel Etherexpress 16 driver.</para>
</listitem>
<listitem>
<para>Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).</para>
</listitem>
<listitem>
<para>Support Adaptec 3985 (first as a simple 3 channel
SCSI card) Coordinator: &a.gibbs;</para>
</listitem>
<listitem>
<para>Support Advansys SCSI controller products.
Coordinator: &a.gibbs;</para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Medium priority tasks</title>
<para>The following tasks need to be done, but not with any
particular urgency:</para>
<orderedlist>
<listitem>
<para>Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth Jones <email>ajones@ctron.com</email></para>
</listitem>
<listitem>
<para>MCA support? This should be finalized one way or the
other.</para>
</listitem>
<listitem>
<para>Full LKM based driver support/Configuration Manager.</para>
<itemizedlist>
<listitem>
<para>Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.</para>
</listitem>
<listitem>
<para>Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>PCMCIA/PCCARD. Coordinators: &a.nate; and &a.phk;</para>
<itemizedlist>
<listitem>
<para>Documentation!</para>
</listitem>
<listitem>
<para>Reliable operation of the pcic driver (needs
testing).</para>
</listitem>
<listitem>
<para>Recognizer and handler for
<filename>sio.c</filename> (mostly done).</para>
</listitem>
<listitem>
<para>Recognizer and handler for
<filename>ed.c</filename> (mostly done).</para>
</listitem>
<listitem>
<para>Recognizer and handler for
<filename>ep.c</filename> (mostly done).</para>
</listitem>
<listitem>
<para>User-mode recognizer and handler (partially
done).</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Advanced Power Management. Coordinators: &a.nate; and
&a.phk;</para>
<itemizedlist>
<listitem>
<para>APM sub-driver (mostly done).</para>
</listitem>
<listitem>
<para>IDE/ATA disk sub-driver (partially done).</para>
</listitem>
<listitem>
<para>syscons/pcvt sub-driver.</para>
</listitem>
<listitem>
<para>Integration with the PCMCIA/PCCARD drivers
(suspend/resume).</para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Low priority tasks</title>
<para>The 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:</para>
<para>The first 20 items are from Terry Lambert
<email>terry@lambert.org</email></para>
<orderedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.</para>
</listitem>
<listitem>
<para>Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.</para>
</listitem>
<listitem>
<para>Streams to allow the use of commercial streams drivers.</para>
</listitem>
<listitem>
<para>Kernel multithreading (requires kernel preemption).</para>
</listitem>
<listitem>
<para>Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).</para>
</listitem>
<listitem>
<para>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).</para>
</listitem>
<listitem>
<para>Reorganization of the source tree for multiple platform
ports.</para>
</listitem>
<listitem>
<para>A <command>make world</command> that "makes the world" (rename the
current one to <command>make regress</command> if that is all it is good
for).</para>
</listitem>
<listitem>
<para>A 4M (preferably smaller!) memory footprint.</para>
</listitem>
</orderedlist>
</sect2>
<sect2>
<title>Smaller tasks</title>
<para>Most 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 &quot;weekend hackers&quot;,
or people without programming skills.</para>
<orderedlist>
<listitem>
<para>If you run FreeBSD-current and have a good Internet
connection, there is a machine <hostid role="fqdn">current.freebsd.org</hostid> which
builds a full release once a day &mdash; every now and again, try
and install the latest release from it and report any
failures in the process.</para>
</listitem>
<listitem>
<para>Read the <email>freebsd-bugs</email> 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.</para>
</listitem>
<listitem>
<para>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).</para>
</listitem>
<listitem>
<para>Help translate FreeBSD documentation into your native
language (if not already available) &mdash; 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 &mdash; in fact, the documentation
most in need of translation is the installation
instructions.</para>
</listitem>
<listitem>
<para>Read the freebsd-questions mailing list and the
newsgroup <literal>comp.unix.bsd.freebsd.misc</literal> 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.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>Move contributed software to
<filename>src/contrib</filename> in the source tree.</para>
</listitem>
<listitem>
<para>Make sure code in <filename>src/contrib</filename> is up
to date.</para>
</listitem>
<listitem>
<para>Look for year 2000 bugs (and fix any you find!)</para>
</listitem>
<listitem>
<para>Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.</para>
</listitem>
<listitem>
<para>Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.</para>
</listitem>
<listitem>
<para>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)</para>
</listitem>
<listitem>
<para>Suggest further tasks for this list!</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1>
<title>How to Contribute</title>
<para>Contributions to the system generally fall into one or more of
the following 6 categories:</para>
<sect2 id="contrib-general">
<title>Bug reports and general commentary</title>
<para>An idea or suggestion of <emphasis>general</emphasis>
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
<emphasis>high</emphasis> volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
<link linkend="eresources-mail">mailing lists</link> for more
information about this and other mailing lists.</para>
<para>If you find a bug or are submitting a specific change, please
report it using the <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry>program or its
<ulink URL="http://www.freebsd.org/send-pr.html">WEB-based
equivalent</ulink>. 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
<citerefentry><refentrytitle>uuencode</refentrytitle><manvolnum>1</manvolnum></citerefentry> if they exceed 20KB.</para>
<para>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 <email>bug-followup@FreeBSD.ORG</email>. Use the number as the message subject, e.g. <literal>"Re: kern/3377"</literal>. Additional information for any bug report should be submitted this way.</para>
<para>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 <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry> command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.</para>
</sect2>
<sect2>
<title>Changes to the documentation</title>
<para>Changes to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
<command>send-pr</command> as described in
<link linkend="contrib-general">Bug Reports and General
Commentary</link>.</para>
</sect2>
<sect2>
<title>Changes to existing source code</title>
<para>An 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
&ldquo;FreeBSD-current&rdquo; which is made available in a variety of ways
for the convenience of developers working actively on the system.
See <link linkend="current">Staying current with FreeBSD</link>
for more information
about getting and using FreeBSD-current.</para>
<para>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.</para>
<para>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 <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, with the &ldquo;context diff&rdquo;
form being preferred. For example:</para>
<para><informalexample>
<screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen>
</informalexample>
or
<informalexample>
<screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen>
</informalexample>
would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more details.</para>
<para>Once you have a set of diffs (which you may test with the
<citerefentry><refentrytitle>patch</refentrytitle><manvolnum>1</manvolnum></citerefentry> command), you should submit them for
inclusion with FreeBSD. Use the <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry>
program as described in
<link linkend="contrib-general">Bug Reports and General
Commentary</link>. <emphasis>Do not</emphasis> 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.</para>
<para>If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a <command>tar</command> file and run the
<citerefentry><refentrytitle>uuencode</refentrytitle><manvolnum>1</manvolnum></citerefentry> program on it. Shar archives are
also welcome.</para>
<para>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 <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry>. 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
<emphasis>very busy</emphasis> and so you should only send mail to
them where it is truly necessary.</para>
<para>Please refer to <command>man 9 intro</command> and
<command>man 9 style</command> for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.</para>
</sect2>
<sect2>
<title>New code or major value-added packages</title>
<para>In 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 <ulink
URL="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming">ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming</ulink>.</para>
<para>When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:</para>
<orderedlist>
<listitem>
<para>The BSD copyright. This copyright is most preferred due
to its &ldquo;no strings attached&rdquo; 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.</para>
</listitem>
<listitem>
<para>The GNU Public License, or &ldquo;GPL&rdquo;. 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 <filename>/sys/gnu</filename> or
<filename>/usr/src/gnu</filename>, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.</para>
</listitem>
</orderedlist>
<para>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.</para>
<para>To place a &ldquo;BSD-style&rdquo; 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
<literal>%%</literal> with the appropriate information.</para>
<programlisting>
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.
&#36;Id&#36;</programlisting>
<para>For your convenience, a copy of this text can
be found in
<filename>/usr/share/examples/etc/bsd-style-copyright</filename>.</para>
</sect2>
<sect2 id="porting">
<title>Porting an existing piece of free software</title>
<para><emphasis>Contributed by &a.jkh;, &a.gpalmer;, &a.asami; and
&a.obrien;.<!-- <br> -->28 August 1996.</emphasis></para>
<para>The porting of freely available software, while perhaps not as
gratifying as developing your own from scratch, is still a vital
part of FreeBSD's growth and of great usefulness to those who
would not otherwise know where to turn for it. All ported
software is organized into a carefully organized hierarchy known
as &ldquo;the ports collection&rdquo;. The collection enables a new user to
get a quick and complete overview of what is available for FreeBSD
in an easy-to-compile form. It also saves considerable space by
not actually containing the majority of the sources being ported,
but merely those differences required for running under FreeBSD.</para>
<para>What follows are some guidelines for creating a new port for
FreeBSD 3.x. The bulk of the work is done by
<filename>/usr/share/mk/bsd.port.mk</filename>, 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.</para>
<sect3 id="porting-starting">
<title>Before Starting the Port</title>
<note>
<para>Only a fraction of the overridable variables
are mentioned in
this document. Most (if not all) are documented at the start
of <filename>bsd.port.mk</filename>. This file uses a
non-standard tab setting. <command>Emacs</command> and
<command>Vim</command> should recognize the setting on loading
the file. <command>vi</command> or <command>ex</command> can
be set to using the correct value by typing <literal>:set
tabstop=4</literal> once the file has been loaded.</para>
</note>
<para>You 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.</para>
<para>The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
<acronym>BSD</acronym> macro defined in
<filename>&lt;sys/param.h&gt;</filename>. Hopefully that file
is already included; if not, add the code:</para>
<programlisting>
#ifdef (defined(__unix__) || defined(unix)) &amp;&amp; !defined(USG)
#include &lt;sys/param.h&gt;
#endif</programlisting>
<para>to the proper place in the <filename>.c</filename> file. We
believe that every system that defines these to symbols has
<filename>sys/param.h</filename>. If you find a system that
doesn't, we would like to know. Please send mail to
&a.ports;.</para>
<para>Another way is to use the GNU Autoconf style of doing
this:</para>
<programlisting>
#ifdef HAVE_SYS_PARAM_H
#include &lt;sys/param.h&gt;
#endif</programlisting>
<para>Don't forget to add <literal>-DHAVE_SYS_PARAM_H</literal> to
the <makevar>CFLAGS</makevar> in the Makefile for this
method.</para>
<para>Once you have <filename>sys/param.h</filename>
included, you may use:</para>
<programlisting>
#if (defined(BSD) &amp;&amp; (BSD &gt;= 199103))</programlisting>
<para>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).</para>
<para>Use:</para>
<programlisting>
#if (defined(BSD) &amp;&amp; (BSD &gt;= 199306))</programlisting>
<para>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).</para>
<para>The value of the BSD macro is 199506 for the 4.4BSD-Lite2
code base. This is stated for informational purposes only. It
should not be used to distinguish between version of FreeBSD
based only on 4.4-Lite vs. versions that have merged in changes
from 4.4-Lite2. The __FreeBSD__ macro should be used
instead.</para>
<para>Use sparingly:</para>
<itemizedlist>
<listitem>
<para><literal>__FreeBSD__</literal> is defined in all
versions of FreeBSD. Use it if the change you are making
ONLY affects FreeBSD. Porting gotchas like the use of
<literal>sys_errlist[]</literal> vs
<function>strerror()</function> are Berkeleyisms, not
FreeBSD changes.</para>
</listitem>
<listitem>
<para>In FreeBSD 2.x, <literal>__FreeBSD__</literal> is
defined to be <literal>2</literal>. In earlier
versions, it is <literal>1</literal>. Later
versions will bump it to match their major version number.</para>
</listitem>
<listitem>
<para>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 <acronym>BSD</acronym> macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
<command>ld</command>) then it is OK to use
<literal>__FreeBSD__</literal> and <literal>#if
__FreeBSD__ &gt; 1</literal> 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:</para>
<programlisting>
#if __FreeBSD__ &gt;= 2
#include &lt;osreldate.h&gt;
# if __FreeBSD_version &gt;= 199504
/* 2.0.5+ release specific code here */
# endif
#endif</programlisting>
<informaltable frame="none">
<tgroup cols="2">
<thead>
<row>
<entry>Release</entry>
<entry><literal>_FreeBSD_version</literal></entry>
</row>
</thead>
<tbody>
<row>
<entry>2.0-RELEASE</entry>
<entry>119411</entry>
</row>
<row>
<entry>2.1-currents</entry>
<entry>199501, 199503</entry>
</row>
<row>
<entry>2.0.5-RELEASE</entry>
<entry>199504</entry>
</row>
<row>
<entry>2.2-current before 2.1</entry>
<entry>199508</entry>
</row>
<row>
<entry>2.1.0-RELEASE</entry>
<entry>199511</entry>
</row>
<row>
<entry>2.2-current before 2.1.5</entry>
<entry>199512</entry>
</row>
<row>
<entry>2.1.5-RELEASE</entry>
<entry>199607</entry>
</row>
<row>
<entry>2.2-current before 2.1.6</entry>
<entry>199608</entry>
</row>
<row>
<entry>2.1.6-RELEASE</entry>
<entry>199612</entry>
</row>
<row>
<entry>2.1.7-RELEASE</entry>
<entry>199612</entry>
</row>
<row>
<entry>2.2-RELEASE</entry>
<entry>220000</entry>
</row>
<row>
<entry>2.2.1-RELEASE</entry>
<entry>220000 (no change)</entry>
</row>
<row>
<entry>2.2-STABLE after 2.2.1-RELEASE</entry>
<entry>220000 (no change)</entry>
</row>
<row>
<entry>2.2-STABLE after texinfo-3.9</entry>
<entry>221001</entry>
</row>
<row>
<entry>2.2-STABLE after top</entry>
<entry>221002</entry>
</row>
<row>
<entry>2.2.2-RELEASE</entry>
<entry>222000</entry>
</row>
<row>
<entry>2.2-STABLE after 2.2.2-RELEASE</entry>
<entry>222001</entry>
</row>
<row>
<entry>2.2.5-RELEASE</entry>
<entry>225000</entry>
</row>
<row>
<entry>2.2-STABLE after 2.2.5-RELEASE</entry>
<entry>225001</entry>
</row>
<row>
<entry>2.2-STABLE after ldconfig -R merge</entry>
<entry>225002</entry>
</row>
<row>
<entry>2.2.6-RELEASE</entry>
<entry>226000</entry>
</row>
<row>
<entry>2.2.7-RELEASE</entry>
<entry>227000</entry>
</row>
<row>
<entry>2.2-STABLE after 2.2.7-RELEASE</entry>
<entry>227001</entry>
</row>
<row>
<entry>3.0-current before mount(2) change</entry>
<entry>300000</entry>
</row>
<row>
<entry>3.0-current as of November 1996</entry>
<entry>300001</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
</itemizedlist>
<note>
<para>Note that 2.2-STABLE sometimes identifies itself as
&ldquo;2.2.5-STABLE&rdquo; after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.</para>
</note>
<para>In the hundreds of ports that have been done, there have
only been one or two cases where <literal>__FreeBSD__</literal>
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.</para>
</sect3>
<sect3>
<title>Quick Porting</title>
<para>This section tells you how to do a quick port. In many
cases, it is not enough, but we will see.</para>
<para>First, get the original tarball and put it into <makevar>DISTDIR</makevar>, which defaults to
<filename>/usr/ports/distfiles</filename>.</para>
<note>
<para>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.</para>
</note>
<sect4>
<title>Writing the <filename>Makefile</filename></title>
<para>The minimal <filename>Makefile</filename> would
look something like this:</para>
<programlisting>
# New ports collection makefile for: oneko
# Version required: 1.1b
# Date created: 5 December 1994
# Whom: asami
#
# &#36;Id&#36;
#
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 &lt;bsd.port.mk&gt;</programlisting>
<para>See if you can figure it out. Do not worry about the
contents of the <literal>&#36;Id&#36;</literal>
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 <link
linkend="porting-samplem">sample Makefile</link>
section.</para>
</sect4>
<sect4>
<title>Writing the description files</title>
<para>There are three required description files that are
required for any port, whether they actually package or not.
They are <filename>COMMENT</filename>,
<filename>DESCR</filename>, and <filename>PLIST</filename>,
and reside in the <filename>pkg</filename>
subdirectory.</para>
<sect5>
<title><filename>COMMENT</filename></title>
<para>This is the one-line description of the port.
<emphasis>Please</emphasis> do not include the package name (or version
number of the software) in the comment. Here is
an example:</para>
<programlisting>
A cat chasing a mouse all over the screen.</programlisting>
</sect5>
<sect5>
<title><filename>DESCR</filename></title>
<para>This is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.</para>
<note>
<para>This is <emphasis>not</emphasis> a manual nor an
in-depth description on how to use or compile the port. In
particular, <emphasis>please do not just copy the
<filename>README</filename> file here</emphasis>, unless,
of course, it is a concise description of the port.</para>
</note>
<para>It is recommended that you sign the name at the end of
this file, as in:</para>
<programlisting>
This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
:
(etc.)
- Satoshi
asami@cs.berkeley.edu</programlisting>
</sect5>
<sect5>
<title><filename>PLIST</filename></title>
<para>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
<filename>/usr/local</filename> or
<filename>/usr/X11R6</filename>). Also it is assumed the
manpages will be compressed.</para>
<para>Here is a small example:</para>
<programlisting>
bin/oneko
man/man1/oneko.1.gz
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm</programlisting>
<para>Refer to the <citerefentry><refentrytitle>pkg_create</refentrytitle><manvolnum>1</manvolnum></citerefentry> man page
for details on the packing list.</para>
</sect5>
</sect4>
<sect4>
<title>Creating the checksum file</title>
<para>Just type <command>make makesum</command>.
The ports make rules will automatically generate the file
<filename>files/md5</filename>.</para>
</sect4>
<sect4>
<title>Testing the port</title>
<para>You should make sure that the port rules do exactly what
you want it to do, including packaging up the port. Try doing
<command>make install</command>, <command>make package</command> and then <command>make deinstall</command> and see if all the files
and directories are correctly deleted. Then do a <command>pkg_add `make package-name`.tgz</command> and see
if everything re-appears and works correctly. Then do another
<command>make deinstall</command> and then
<command>make reinstall; make package</command>
to make sure you haven't included in the packing list any
files that are not installed by your port.</para>
</sect4>
<sect4 id="porting-submitting">
<title>Submitting the port</title>
<para>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. To accomplish this, pack
the necessary files (everything described in this section &mdash;
in particular do <emphasis>not</emphasis> include the original
source tarball, the <filename>work</filename>
subdirectory or the package) into a
<filename>.tar.gz</filename> file, stick it in the directory
<filename>ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/</filename> and send mail to us using
<citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry> (please classify it as category
<literal>ports</literal> and class <literal>change-request</literal>). There is no need to
upload the package, we will build it by ourselves. We will
take a look, get back to you if necessary, and put it in the
tree. Your name will also appear in the list of &ldquo;Additional
FreeBSD contributors&rdquo; on the FreeBSD Handbook and other files.
Isn't that great?!? <!-- smiley -->:)</para>
</sect4>
</sect3>
<sect3>
<title>Slow Porting</title>
<para>Ok, 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.</para>
<sect4>
<title>How things work</title>
<para>First, this is the sequence of events which occurs when
the user first types <command>make</command> in
your port's directory, and you may find that having
<filename>bsd.port.mk</filename> in another window while you
read this really helps to understand it.</para>
<para>But do not worry if you do not really understand what
<filename>bsd.port.mk</filename> is doing, not many people
do... <!-- smiley --><emphasis>:&gt;</emphasis></para>
<procedure>
<step>
<para>The <maketarget>fetch</maketarget> target is run. The <maketarget>fetch</maketarget> target is
responsible for making sure that the tarball exists
locally in <makevar>DISTDIR</makevar>.
If <maketarget>fetch</maketarget> cannot find the required files in <makevar>DISTDIR</makevar> it will look up the
URL <makevar>MASTER_SITES</makevar>,
which is set in the Makefile, as well as our main ftp
site at <ulink
URL="ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/">ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/,</ulink> where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with <makevar>FETCH</makevar>, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in <makevar>DISTDIR</makevar> for future use and proceed.</para>
</step>
<step>
<para>The <maketarget>extract</maketarget> target is run. It looks for your ports'
distribution file in <makevar>DISTDIR</makevar> (typically a gzip'd
tarball) and unpacks it into a temporary subdirectory
specified by <makevar>WRKDIR</makevar>
(defaults to <filename>work</filename>).</para>
</step>
<step>
<para>The <maketarget>patch</maketarget> target is run. First, any patches defined
in <makevar>PATCHFILES</makevar> are
applied. Second, if any patches are found in <makevar>PATCHDIR</makevar> (defaults to the
<filename>patches</filename> subdirectory), they are
applied at this time in alphabetical order.</para>
</step>
<step>
<para>The <maketarget>configure</maketarget> target is run. This can do any one of
many different things.</para>
<orderedlist>
<listitem>
<para>If it exists,
<filename>scripts/configure</filename> is run.</para>
</listitem>
<listitem>
<para>If <makevar>HAS_CONFIGURE</makevar> or
<makevar>GNU_CONFIGURE</makevar>
is set,
<filename><makevar>WRKSRC</makevar>/configure</filename> is
run.</para>
</listitem>
<listitem>
<para>If <makevar>USE_IMAKE</makevar> is set,
<makevar>XMKMF</makevar>
(default: <command>xmkmf
-a</command>) is run.</para>
</listitem>
</orderedlist>
</step>
<step>
<para>The <maketarget>build</maketarget> target is run. This is responsible for
descending into the ports' private working directory
(<makevar>WRKSRC</makevar>) and
building it. If <makevar>USE_GMAKE</makevar> is set, GNU
<command>make</command> will be used,
otherwise the system <command>make</command>
will be used.</para>
</step>
</procedure>
<para>The above are the default actions. In addition, you can
define targets <maketarget>pre-<replaceable>something</replaceable></maketarget> or <maketarget>post-<replaceable>something</replaceable></maketarget>, or put scripts
with those names, in the <filename>scripts</filename>
subdirectory, and they will be run before or after the default
actions are done.</para>
<para>For example, if you have a <maketarget>post-extract</maketarget> target defined in your
Makefile, and a file <filename>pre-build</filename> in the
<filename>scripts</filename> subdirectory, the
<maketarget>post-extract</maketarget> target will be
called after the regular extraction actions, and the
<filename>pre-build</filename> script will be executed before
the default build rules are done. It is recommended that you
use <filename>Makefile</filename> 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.</para>
<para>The default actions are done by the
<filename>bsd.port.mk</filename> targets <maketarget>do-<replaceable>something</replaceable></maketarget>. For example, the
commands to extract a port are in the target <maketarget>do-extract</maketarget>. If you are not happy with
the default target, you can fix it by redefining the
<maketarget>do-<replaceable>something</replaceable></maketarget> target in
your <filename>Makefile</filename>.</para>
<note>
<para>The &ldquo;main&rdquo; targets (e.g., <maketarget>extract</maketarget>, <maketarget>configure</maketarget>, etc.) do nothing more than
make sure all the stages up to that one is completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
<maketarget>do-extract</maketarget>, but never ever
touch <maketarget>extract</maketarget>!</para>
</note>
<para>Now that you understand what goes on when the user types
<command>make</command>, let us go through the
recommended steps to create the perfect port.</para>
</sect4>
<sect4>
<title>Getting the original sources</title>
<para>Get the original sources (normally) as a compressed
tarball (<filename><replaceable>foo</replaceable>.tar.gz</filename> or
<filename><replaceable>foo</replaceable>.tar.Z</filename>) and copy it into
<makevar>DISTDIR</makevar>. Always use
<emphasis>mainstream</emphasis> sources when and where you
can.</para>
<para>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, we can &ldquo;house&rdquo; it ourselves by putting
it on <filename>ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/</filename> as the last resort. Please refer to this
location as <makevar>MASTER_SITE_LOCAL</makevar>. Send mail to
the &a.ports;if you are not sure what to do.</para>
<para>If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
<makevar>DISTDIR</makevar>. Do not worry if
they come from site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of <link
linkend="porting-patchfiles">PATCHFILES</link> below).</para>
</sect4>
<sect4>
<title>Modifying the port</title>
<para>Unpack 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
<emphasis>careful track</emphasis> 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.</para>
<para>If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic <application>Configure</application> scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as &ldquo;plug-and-play&rdquo;
as possible for the end-user while using a minimum of disk
space.</para>
<note>
<para>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.</para>
</note>
</sect4>
<sect4>
<title>Patching</title>
<para>In 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
<filename>patch-<replaceable>xx</replaceable></filename> where
<replaceable>xx</replaceable> denotes the sequence in which
the patches will be applied &mdash; these are done in
<emphasis>alphabetical order</emphasis>, thus
<literal>aa</literal> first, <literal>ab</literal> second and so on. These files
should be stored in <makevar>PATCHDIR</makevar>, from where they will be
automatically applied. All patches should be relative to
<makevar>WRKSRC</makevar> (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 <makevar>WRKSRC</makevar>/foobar.c).</para>
</sect4>
<sect4>
<title>Configuring</title>
<para>Include any additional customization commands to your
<filename>configure</filename> script and save it in the
<filename>scripts</filename> subdirectory. As mentioned
above, you can also do this as <filename>Makefile</filename>
targets and/or scripts with the name
<filename>pre-configure</filename> or
<filename>post-configure</filename>.</para>
</sect4>
<sect4>
<title>Handling user input</title>
<para>If your port requires user input to build, configure or
install, then set <makevar>IS_INTERACTIVE</makevar> in your
Makefile. This will allow &ldquo;overnight builds&rdquo; to skip your port
if the user sets the variable <envar>BATCH</envar> in his
environment (and if the user sets the variable
<envar>INTERACTIVE</envar>, then <emphasis>only</emphasis>
those ports requiring interaction are built).</para>
</sect4>
</sect3>
<sect3>
<title>Configuring the Makefile</title>
<para>Configuring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a <link linkend="porting-samplem">sample
Makefile</link> 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.</para>
<para>Now, consider the following problems in sequence as you
design your new Makefile:</para>
<sect4>
<title>The original source</title>
<para>Does it live in <makevar>DISTDIR</makevar> 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 <makevar>EXTRACT_CMD</makevar>, <makevar>EXTRACT_BEFORE_ARGS</makevar>, <makevar>EXTRACT_AFTER_ARGS</makevar>, <makevar>EXTRACT_SUFX</makevar>, or <makevar>DISTFILES</makevar> variables, depending on
how alien a format your port's distribution file is. (The
most common case is <literal>EXTRACT_SUFX=.tar.Z</literal>,
when the tarball is condensed by regular compress, not
gzip.)</para>
<para>In the worst case, you can simply create your own
<maketarget>do-extract</maketarget> target to override
the default, though this should be rarely, if ever,
necessary.</para>
</sect4>
<sect4>
<title><makevar>DISTNAME</makevar></title>
<para>You should set <makevar>DISTNAME</makevar> to be the base name of
your port. The default rules expect the distribution file
list (<makevar>DISTFILES</makevar>) to be
named <makevar>DISTNAME</makevar><makevar>EXTRACT_SUFX</makevar> by
default which, if it is a normal tarball, is going to be
something like <literal>foozolix-1.0.tar.gz</literal> for a setting of
<programlisting>
DISTNAME=foozolix-1.0</programlisting>.</para>
<para>The default rules also expect the tarball(s) to extract
into a subdirectory called
<filename>work/<makevar>DISTNAME</makevar></filename>, e.g. <filename>work/foozolix-1.0/</filename>.</para>
<para>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 <makevar>DISTFILES</makevar> explicitly. If only a
subset of <makevar>DISTFILES</makevar> are
actual extractable archives, then set them up in <makevar>EXTRACT_ONLY</makevar>, which will override
the <makevar>DISTFILES</makevar> list when
it comes to extraction, and the rest will be just left in
<makevar>DISTDIR</makevar> for later
use.</para>
</sect4>
<sect4>
<title><makevar>CATEGORIES</makevar></title>
<para>When a package is created, it is put under
<filename>/usr/ports/packages/All</filename> and links are
made from one or more subdirectories of
<filename>/usr/ports/packages</filename>. The names of these
subdirectories are specified by the variable <makevar>CATEGORIES</makevar>. 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 (you can find them in <ulink
URL="http://www.freebsd.org/ports/">the ports
page</ulink>) and pick the ones that are suitable for your
port. If your port truly belongs to something that is
different from all the existing ones, you can even create a
new category name.</para>
</sect4>
<sect4>
<title><makevar>MASTER_SITES</makevar></title>
<para>Record the directory part of the ftp/http-URL pointing at
the original tarball in <makevar>MASTER_SITES</makevar>. Do not forget the
trailing slash (<filename>/</filename>)!</para>
<para>The <command>make</command> macros will try to use this specification for
grabbing the distribution file with <makevar>FETCH</makevar> if they cannot find it
already on the system.</para>
<para>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!</para>
<para>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 <makevar>MASTER_SITE_XCONTRIB</makevar>, <makevar>MASTER_SITE_GNU</makevar>,
<makevar>MASTER_SITE_PERL_CPAN</makevar>, <makevar>MASTER_SITE_TEX_CTAN</makevar>, and
<makevar>MASTER_SITE_SUNSITE</makevar>. Simply set <makevar>MASTER_SITE_SUBDIR</makevar> to the
path with in the archive. Here is an example:</para>
<programlisting>
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applications</programlisting>
<para>The user can also set the <makevar>MASTER_SITE_*</makevar> variables in
<filename>/etc/make.conf</filename> to override our choices,
and use their favorite mirrors of these popular archives
instead.</para>
</sect4>
<sect4 id="porting-patchfiles">
<title><makevar>PATCHFILES</makevar></title>
<para>If your port requires some additional patches that are
available by ftp or http, set <makevar>PATCHFILES</makevar> to the names of the
files and <makevar>PATCH_SITES</makevar> to
the URL of the directory that contains them (the format is the
same as <makevar>MASTER_SITES</makevar>).</para>
<para>If the patch is not relative to the top of the source tree
(i.e., <makevar>WKRSRC</makevar>) because it
contains some extra pathnames, set <makevar>PATCH_DIST_STRIP</makevar> accordingly.
For instance, if all the pathnames in the patch has an extra
<literal>foozolix-1.0/</literal> in front of the
filenames, then set
<literal>PATCH_DIST_STRIP=-p1</literal>.</para>
<para>Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
<filename>.gz</filename> or
<filename>.Z</filename>.</para>
<para>If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
<makevar>PATCHFILES</makevar>. If that is
the case, add the name and the location of the patch tarball
to <makevar>DISTFILES</makevar> and
<makevar>MASTER_SITES</makevar>. Then, from
the <maketarget>pre-patch</maketarget> target, apply the
patch either by running the patch command from there, or
copying the patch file into the <makevar>PATCHDIR</makevar> directory and calling it
<filename>patch-<replaceable>xx</replaceable></filename>.</para>
<note>
<para>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 <maketarget>pre-clean</maketarget> target.</para>
</note>
</sect4>
<sect4>
<title><makevar>MAINTAINER</makevar></title>
<para>Set your mail-address here. Please. <!-- smiley --><emphasis>:)</emphasis></para>
<para>For detailed description of the responsibility of
maintainers, refer to <link
linkend="policies-maintainer">MAINTAINER
on Makefiles</link> section.</para>
</sect4>
<sect4>
<title>Dependencies</title>
<para>Many 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.</para>
<sect5>
<title><makevar>LIB_DEPENDS</makevar></title>
<para>This variable specifies the shared libraries this port
depends on. It is a list of <replaceable>lib</replaceable>:<replaceable>dir</replaceable> pairs where
<replaceable>lib</replaceable> is the name of the shared library,
and <replaceable>dir</replaceable> is the directory in which to
find it in case it is not available. For example,
<programlisting>
LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg</programlisting>
will check for a shared jpeg library with
major version 6, and descend into the
<filename>graphics/jpeg</filename> subdirectory of your
ports tree to build and install it if it is not
found.</para>
<note>
<para>The <replaceable>lib</replaceable> part is just an argument
given to <command>ldconfig -r | grep</command>, so
periods should be escaped by two backslashes like in the
example above.</para>
</note>
<para>The dependency is checked from within the <maketarget>extract</maketarget> target. Also, the name of the
dependency is put in to the package so that
<command>pkg_add</command> will automatically install it if it
is not on the user's system.</para>
</sect5>
<sect5>
<title><makevar>RUN_DEPENDS</makevar></title>
<para>This variable specifies executables or files this port
depends on during run-time. It is a list of <replaceable>path</replaceable>:<replaceable>dir</replaceable> pairs where
<replaceable>path</replaceable> is the name of the executable or
file, and <replaceable>dir</replaceable> is the directory in which
to find it in case it is not available. If
<replaceable>path</replaceable> starts with a slash
(<literal>/</literal>), it is treated as a file and its
existence is tested with <command>test -e</command>;
otherwise, it is assumed to be an executable, and
<command>which -s</command> is used to determine if the
program exists in the user's search path.</para>
<para>For example,
<programlisting>
RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish:${PORTSDIR}/x11/tk</programlisting>
will check if the file
<filename>/usr/local/etc/innd</filename> exists, and build
and install it from the <filename>news/inn</filename>
subdirectory of the ports tree if it is not found. It will
also see if an executable called <command>wish</command> is in your search path, and
descend into the <filename>x11/tk</filename> subdirectory of
your ports tree to build and install it if it is not
found.</para>
<note>
<para>In this case, <command>innd</command> 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.</para>
</note>
<para>The dependency is checked from within the <maketarget>install</maketarget> target. Also, the name of the
dependency is put in to the package so that
<command>pkg_add</command> will automatically install it if it
is not on the user's system.</para>
</sect5>
<sect5>
<title><makevar>BUILD_DEPENDS</makevar></title>
<para>This variable specifies executables or files this port
requires to build. Like <makevar>RUN_DEPENDS</makevar>, it is
a list of <replaceable>path</replaceable>:<replaceable>dir</replaceable> pairs.
For example,
<programlisting>
BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip</programlisting>
will check for an executable called
<command>unzip</command>, and descend into the
<filename>archivers/unzip</filename> subdirectory of your
ports tree to build and install it if it is not
found.</para>
<note>
<para>&ldquo;build&rdquo; here means everything from extracting to
compilation. The dependency is checked from within the
<maketarget>extract</maketarget> target.</para>
</note>
</sect5>
<sect5>
<title><makevar>FETCH_DEPENDS</makevar></title>
<para>This variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
<replaceable>path</replaceable>:<replaceable>dir</replaceable> pairs. For
example,
<programlisting>
FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2</programlisting>
will check for an executable called
<command>ncftp2</command>, and descend into the
<filename>net/ncftp2</filename> subdirectory of your ports
tree to build and install it if it is not found.</para>
<para>The dependency is checked from within the <maketarget>fetch</maketarget> target.</para>
</sect5>
<sect5>
<title><makevar>DEPENDS</makevar></title>
<para>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 (i.e., having them
installed is not enough), then use this variable. This is
just a list of directories, as there is nothing to check,
unlike the previous four.</para>
</sect5>
</sect4>
<sect4>
<title>Building mechanisms</title>
<para>If your package uses GNU <command>make</command>, set
<literal>USE_GMAKE=yes</literal>. If your package uses GNU
<command>configure</command>, set
<literal>GNU_CONFIGURE=yes</literal>. If you want to give
some extra arguments to GNU <command>configure</command> (other than the default
<literal>--prefix=&#36;{PREFIX}</literal>), set those extra
arguments in <makevar>CONFIGURE_ARGS</makevar>.</para>
<para>If your package is an X application that creates
<filename>Makefile</filename>s from
<filename>Imakefile</filename>s using <command>imake</command>, then set
<literal>USE_IMAKE=yes</literal>. This will cause the
configure stage to automatically do an <command>xmkmf
-a</command>. If the <option>-a</option> flag is a
problem for your port, set
<literal>XMKMF=xmkmf</literal>.</para>
<para>If your port's source <filename>Makefile</filename> has
something else than <maketarget>all</maketarget> as the
main build target, set <makevar>ALL_TARGET</makevar> accordingly. Same
goes for <maketarget>install</maketarget> and <makevar>INSTALL_TARGET</makevar>.</para>
</sect4>
<sect4>
<title><makevar>NO_INSTALL_MANPAGES</makevar></title>
<para>If the port uses <command>imake</command> but does not understand the
<filename>install.man</filename> target,
<literal>NO_INSTALL_MANPAGES=yes</literal> should be set.
In addition, the author of the original port should be shot.
<!-- smiley --><emphasis>:&gt;</emphasis></para>
</sect4>
</sect3>
<sect3>
<title>Ports that require Motif</title>
<para>There are many programs that require a Motif library
(available from several commercial vendors, while there is (at
least) one effort to create a free clone) 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 or statically.</para>
<sect4>
<title><makevar>REQUIRES_MOTIF</makevar></title>
<para>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.</para>
</sect4>
<sect4>
<title><makevar>MOTIFLIB</makevar></title>
<para>This variable will be set by
<filename>bsd.port.mk</filename> 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.</para>
<para>There are two common cases:</para>
<orderedlist>
<listitem>
<para>If the port refers to the Motif library as
<option>-lXm</option> in its Makefile or Imakefile,
simply substitute <makevar>MOTIFLIB</makevar> for it.</para>
</listitem>
<listitem>
<para>If the port uses <literal>XmClientLibs</literal> in its Imakefile,
change it to <literal>&#36;{MOTIFLIB}
&#36;{XTOOLLIB} &#36;{XLIB}</literal>.</para>
</listitem>
</orderedlist>
<note>
<para><makevar>MOTIFLIB</makevar> (usually)
expands to <literal>-L/usr/X11R6/lib -lXm</literal> or
<literal>/usr/X11R6/lib/libXm.a</literal>, so there is
no need to add <option>-L</option> or
<option>-l</option> in front.</para>
</note>
</sect4>
</sect3>
<sect3>
<title>Info files</title>
<para>The new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called <command>install-info</command> to add and delete entries to
the <filename>dir</filename> file. If your port installs any
info documents, please follow these instructions so your
port/package will correctly update the user's
<filename>&#36;{PREFIX}/info/dir</filename> file. (Sorry for
the length of this section, but it is imperative to weave all
the info files together. If done correctly, it will produce a
<emphasis>beautiful</emphasis> listing, so please bear with me!
<!-- smiley --><emphasis>:)</emphasis></para>
<para>First, this is what you (as a porter) need to know:</para>
<informalexample>
<screen>&prompt.user; <userinput>install-info --help</userinput>
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. :</screen>
</informalexample>
<note>
<para>This program will not actually
<emphasis>install</emphasis> info files; it merely inserts or
deletes entries in the <filename>dir</filename> file.</para>
</note>
<para>Here's a seven-step procedure to convert ports to use
<command>install-info</command>. I will use
<filename>editors/emacs</filename> as an example.</para>
<procedure>
<step>
<para>Look at the texinfo sources and make a patch to insert
<literal>@dircategory</literal> and <literal>@direntry</literal>
statements to files that don't have them. This is part of
my patch:</para>
<programlisting>
--- ./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
:</programlisting>
<para>The format should be self-explanatory. Many authors
leave a <filename>dir</filename> 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).</para>
<note>
<para>Note that you can put only one info entry per file
because of a bug in <command>install-info
--delete</command> that deletes only the first entry
if you specify multiple entries in the
<email>@direntry</email> section.</para>
</note>
<para>You can give the <literal>dir</literal>
entries to <command>install-info</command> as
arguments (<option>--section</option> and
<option>--entry</option>) 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
<emphasis>three</emphasis> places
(<filename>Makefile</filename> and
<literal>@exec</literal>/<literal>@unexec</literal> of
<filename>PLIST</filename>; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to <command>install-info</command> because <command>makeinfo</command> can't handle those texinfo
sources. (See <filename>Makefile</filename> and
<filename>PLIST</filename> of
<filename>japanese/skk</filename> for examples on how to
do this).</para>
</step>
<step>
<para>Go back to the port directory and do a <command>make clean; make</command> 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 <command>make</command>; but many
<filename>Makefile</filename>s don't include correct
dependencies for info files. In <command>emacs</command>' case, I had to
patch the main <filename>Makefile.in</filename> so it will
descend into the <filename>man</filename>
subdirectory to rebuild the info pages.</para>
<programlisting>
--- ./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)</programlisting>
<para>The second hunk was necessary because the default
target in the <filename>man</filename> subdir is called
<maketarget>info</maketarget>, while the main
<filename>Makefile</filename> wants to call <maketarget>all</maketarget>. I also deleted the installation
of the <filename>info</filename> info file
because we already have one with the same name in
<filename>/usr/share/info</filename> (that patch is not
shown here).</para>
</step>
<step>
<para>If there is a place in the
<filename>Makefile</filename> that is installing the
<filename>dir</filename> file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
<filename>dir</filename> file.</para>
<programlisting>
--- ./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); \</programlisting>
</step>
<step>
<para>(This step is only necessary if you are modifying an
existing port.) Take a look at
<filename>pkg/PLIST</filename> and delete anything that is
trying to patch up <filename>info/dir</filename>. They
may be in <filename>pkg/INSTALL</filename> or some other
file, so search extensively.</para>
<programlisting>
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-2</programlisting>
</step>
<step>
<para>Add a <maketarget>post-install</maketarget>
target to the <filename>Makefile</filename> to create a
<filename>dir</filename> file if it is not there. Also,
call <maketarget>install-info</maketarget> with the
installed info files.</para>
<programlisting>
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 &lt;bsd.port.mk&gt;</programlisting>
<para>Do not use anything other than
<filename>/usr/share/info/dir</filename> and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
<filename>bsd.port.mk</filename> if you (the porter)
wouldn't have to do it in <filename>PLIST</filename> by
yourself anyway.</para>
</step>
<step>
<para>Edit <filename>PLIST</filename> and add equivalent
<literal>@exec</literal> statements and also
<literal>@unexec</literal> for <command>pkg_delete</command>.
You do not need to delete <filename>info/dir</filename>
with <literal>@unexec</literal>.</para>
<programlisting>
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-doc</programlisting>
<note>
<para>The <literal>@unexec install-info
--delete</literal> commands have to be listed before
the info files themselves so they can read the files.
Also, the <literal>@exec install-info</literal> commands
have to be after the info files and the
<literal>@exec</literal> command that creates the the
<filename>dir</filename> file.</para>
</note>
</step>
<step>
<para>Test and admire your work. <!-- smiley --><emphasis>:)</emphasis> The sequence I recommend is:
<command>make package</command>,
<command>pkg_delete</command>, then
<command>pkg_add</command>. Check the <filename>dir</filename> file before and after each
step.</para>
</step>
</procedure>
</sect3>
<sect3>
<title>Licensing Problems</title>
<para>Some software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
can do with them vary a lot, depending on the exact wordings of
the respective licenses.</para>
<note>
<para>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;.</para>
</note>
<para>There are two variables you can set in the Makefile to
handle the situations that arise frequently:</para>
<orderedlist>
<listitem>
<para>If the port has a &ldquo;do not sell for profit&rdquo; type of
license, set the variable <makevar>NO_CDROM</makevar>. 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.</para>
</listitem>
<listitem>
<para>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
<makevar>NO_PACKAGE</makevar>. 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.</para>
</listitem>
<listitem>
<para>If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a &ldquo;no commercial use&rdquo; license,
set the variable <makevar>RESTRICTED</makevar> to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.</para>
</listitem>
</orderedlist>
<note>
<para>The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.</para>
</note>
<note>
<para>If you are a committer, make sure you update the
<filename>ports/LEGAL</filename> file too.</para>
</note>
</sect3>
<sect3>
<title>Upgrading</title>
<para>When 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
<filename>ports-current</filename> directory of the ftp mirror
sites.</para>
<para>The next step is to send a mail to the maintainer, if one is
listed in the port's <filename>Makefile</filename>. 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).</para>
<para>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 (i.e., if your modified ports
directory is called <filename>superedit</filename>
and the original as in our tree is
<filename>superedit.bak</filename>, then send us the result of
<command>diff -ruN superedit.bak
superedit</command>). 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 <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry>
(category <literal>ports</literal>). 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.</para>
</sect3>
<sect3>
<title>Do's and Dont's</title>
<para>Here is a list of common do's and dont's that you encounter
during the porting process.</para>
<sect4>
<title><makevar>WRKDIR</makevar></title>
<para>Do not leave anything valuable lying around in the
<filename>work</filename> subdirectory, <command>make clean</command> will
<emphasis>nuke</emphasis> it completely! If you need
auxiliary files that are not scripts or patches, put them in
the <makevar>FILESDIR</makevar> subdirectory
(<filename>files</filename> by default) and use the
<maketarget>post-extract</maketarget> target to copy them
to the <filename>work</filename> subdirectory.</para>
</sect4>
<sect4>
<title>Package information</title>
<para>Do include package information, i.e.
<filename>COMMENT</filename>, <filename>DESCR</filename>, and
<filename>PLIST</filename>, in <filename>pkg</filename>.</para>
<note>
<para>Note that these files are not used only for packaging
anymore, and are <emphasis>mandatory</emphasis> now, even if
<makevar>NO_PACKAGE</makevar> is
set.</para>
</note>
</sect4>
<sect4>
<title>Compress manpages, strip binaries</title>
<para>Do compress manpages and strip binaries. If the original
source already strips the binary, fine; otherwise, you can add
a <maketarget>post-install</maketarget> rule to do it
yourself. Here is an example:</para>
<programlisting>
post-install:
strip ${PREFIX}/bin/xdl</programlisting>
<para>Use the <command>file</command> command on the
installed executable to check whether the binary is stripped
or not. If it does not say `not stripped', it is
stripped.</para>
<para>To automagically compress the manpages, use the <makevar>MAN[1-9LN]</makevar>
variables. They will check the variable
<makevar>NOMANCOMPRESS</makevar> that the user can set in
<filename>/etc/make.conf</filename> to disable man page
compression. Place them last in the section below the
<makevar>MAINTAINER</makevar> variable. Here is an example:</para>
<programlisting>
MAN1= foo.1 bar.1
MAN5= foo.conf.5
MAN8= baz.8</programlisting>
<note>
<para>This is not usually necessary with ports that are X
applications and use Imake to build.</para>
</note>
<para>If your port anchors its man tree somewhere other than
<makevar>PREFIX</makevar>, you can use the
<makevar>MANPREFIX</makevar> to set it. Also, if only manpages
in certain section go in a non-standard place, such as many
Perl modules ports, you can set individual man paths using
<makevar>MAN<replaceable>sect</replaceable>PREFIX</makevar>
(where <replaceable>sect</replaceable> is one of 1-9, L or
N).</para>
</sect4>
<sect4>
<title><makevar>INSTALL_*</makevar> macros</title>
<para>Do use the macros provided in
<filename>bsd.port.mk</filename> to ensure correct modes and
ownership of files in your own *-install targets. They
are:</para>
<itemizedlist>
<listitem>
<para><makevar>${INSTALL_PROGRAM}</makevar> is
a command to install binary executables.</para>
</listitem>
<listitem>
<para><makevar>${INSTALL_SCRIPT}</makevar> is a
command to install executable scripts.</para>
</listitem>
<listitem>
<para><makevar>${INSTALL_DATA}</makevar> is a
command to install sharable data.</para>
</listitem>
<listitem>
<para><makevar>${INSTALL_MAN}</makevar> is a
command to install manpages and other documentation (it
doesn't compress anything).</para>
</listitem>
</itemizedlist>
<para>These are basically the <command>install</command> command with all the appropriate
flags. See below for an example on how to use them.</para>
</sect4>
<sect4>
<title><filename>INSTALL</filename> package script</title>
<para>If your port needs execute commands when the binary
package is installed with pkg_add you can do with via the
<filename>pkg/INSTALL</filename> script. This script will
automatically be added to the package, and will be run twice
by pkg_add. The first time will as <command>INSTALL ${PKGNAME} PRE-INSTALL</command> and the
second time as <command>INSTALL ${PKGNAME}
POST-INSTALL</command>. <literal>&#36;2</literal> can be tested to determine which
mode the script is being run in. The
<envar>PKG_PREFIX</envar> environmental variable will be
set to the package installation directory. See man
<citerefentry><refentrytitle>pkg_add</refentrytitle><manvolnum>1</manvolnum></citerefentry> for additional
information.</para>
<note>
<para>This script is not run automatically if you install the
port with <command>make install</command>. If you are
depending on it being run, you will have to explicitly call
it on your port's <filename>Makefile</filename>.</para>
</note>
</sect4>
<sect4>
<title><filename>REQ</filename> package script</title>
<para>If your port needs to determine if it should install or
not, you can create a <filename>pkg/REQ</filename>
&ldquo;requirements&rdquo; script. It will be invoked automatically at
installation/deinstallation time to determine whether or not
installation/deinstallation should proceed. See man
<citerefentry><refentrytitle>pkg_create</refentrytitle><manvolnum>1</manvolnum></citerefentry> and man
<citerefentry><refentrytitle>pkg_add</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more information.</para>
</sect4>
<sect4>
<title>Install additional documentation</title>
<para>If your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
<filename><makevar>PREFIX</makevar>/share/doc</filename>. This can be
done, like the previous item, in the <maketarget>post-install</maketarget> target.</para>
<para>Create a new directory for your port. The directory name
should reflect what the port is. This usually means <makevar>PKGNAME</makevar> 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 <makevar>PKGNAME</makevar>.</para>
<para>Make the installation dependent to the variable
<makevar>NOPORTDOCS</makevar> so that users can disable it in
<filename>/etc/make.conf</filename>, like this:</para>
<programlisting>
post-install:
.if !defined(NOPORTDOCS)
${MKDIR}${PREFIX}/share/doc/xv
${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endif</programlisting>
<para>Do not forget to add them to
<filename>pkg/PLIST</filename> too! (Do not worry about
<makevar>NOPORTDOCS</makevar> here; there is currently no way
for the packages to read variables from
<filename>/etc/make.conf</filename>.)</para>
<para>If you need to display a message to the installer, you may
place the message in <filename>pkg/MESSAGE</filename>. This
capibility is often useful to display additional installation
steps to be taken after a pkg_add, or to display licensing
information.</para>
<note>
<para><filename>MESSAGE</filename> does not need to be added
to <filename>pkg/PLIST</filename>).</para>
</note>
</sect4>
<sect4>
<title><makevar>DIST_SUBDIR</makevar></title>
<para>Do not let your port clutter
<filename>/usr/ports/distfiles</filename>. 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.,
<filename>Makefile</filename>), set <makevar>DIST_SUBDIR</makevar> to the name of the
port (<makevar>PKGNAME</makevar> without the
version part should work fine). This will change <makevar>DISTDIR</makevar> from the default
<filename>/usr/ports/distfiles</filename> to
<filename>/usr/ports/distfiles/<makevar>DIST_SUBDIR</makevar></filename>,
and in effect puts everything that is required for your port
into that subdirectory.</para>
<para>It will also look at the subdirectory with the same name
on the backup master site at
<filename>ftp.freebsd.org</filename>. (Setting <makevar>DISTDIR</makevar> explicitly in your
<makevar>Makefile</makevar> will not accomplish this, so please use <makevar>DIST_SUBDIR</makevar>.)</para>
<note>
<para>This does not affect the <makevar>MASTER_SITES</makevar> you define in your
Makefile.</para>
</note>
</sect4>
<sect4>
<title>Feedback</title>
<para>Do 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.</para>
</sect4>
<sect4>
<title>RCS strings</title>
<para>Do 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 (<literal>&#36;</literal>) signs, and typically start with
<literal>&#36;Id</literal> or <literal>&#36;RCS</literal>.</para>
</sect4>
<sect4>
<title>Recursive diff</title>
<para>Using the recurse (<option>-r</option>) option to
<command>diff</command> 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, <filename>Makefiles</filename> when the
port uses <command>Imake</command> or GNU <command>configure</command>, etc., are unnecessary and
should be deleted. Also, if you had to delete a file, then you
can do it in the <maketarget>post-extract</maketarget>
target rather than as part of the patch. Once you are happy
with the resuling diff, please split it up into one source
file per patch file.</para>
</sect4>
<sect4>
<title><makevar>PREFIX</makevar></title>
<para>Do try to make your port install relative to <makevar>PREFIX</makevar>. (The value of this
variable will be set to <makevar>LOCALBASE</makevar> (default
<filename>/usr/local</filename>), unless <makevar>USE_IMAKE</makevar> or <makevar>USE_X11</makevar> is set, in which case it
will be <makevar>X11BASE</makevar> (default
<filename>/usr/X11R6</filename>).)</para>
<para>Not hard-coding <filename>/usr/local</filename> or
<filename>/usr/X11R6</filename> 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 <command>imake</command>, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of <filename>/usr/local</filename>
(or <filename>/usr/X11R6</filename> for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read <makevar>PREFIX</makevar>, as this
variable is automatically passed down to every stage of the
build and install processes.</para>
<para>The variable <makevar>PREFIX</makevar>
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. (If your port is an X port but does not use <command>imake</command>,
set <literal>USE_X11=yes</literal>; this is quite different
from setting <literal>PREFIX=/usr/X11R6</literal>.)</para>
<para>Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
<literal>PAGER</literal> to be the full pathname of <command>less</command>, use the compiler flag:
<programlisting>
-DPAGER=\"&#36;{PREFIX}/bin/less\"</programlisting>
or
<programlisting>
-DPAGER=\"&#36;{LOCALBASE}/bin/less\"</programlisting>
if this is an X port, instead of <literal>-DPAGER=\"/usr/local/bin/less\".</literal> This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.</para>
</sect4>
<sect4>
<title>Subdirectories</title>
<para>Try to let the port put things in the right subdirectories
of <makevar>PREFIX</makevar>. 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 <filename>lib</filename>, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: <filename>etc</filename>
(setup/configuration files), <filename>libexec</filename>
(executables started internally), <filename>sbin</filename>
(executables for superusers/managers),
<filename>info</filename> (documentation for info browser)
or <filename>share</filename> (architecture independent
files). See man <citerefentry><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details, the rule governing <filename>/usr</filename> pretty
much applies to <filename>/usr/local</filename> too. The
exception are ports dealing with USENET &ldquo;news&rdquo;. They may use
<filename><makevar>PREFIX</makevar>/news</filename> as a destination for
their files.</para>
</sect4>
<sect4>
<title>ldconfig</title>
<para>If your port installs a shared library, add a <maketarget>post-install</maketarget> target to your Makefile
that runs <command>/sbin/ldconfig -m</command> on
the directory where the new library is installed (usually
<filename><makevar>PREFIX</makevar>/lib</filename>) to register it into
the shared library cache.</para>
<para>Also, add an <literal>@exec</literal> line to your
<filename>pkg/PLIST</filename> file so that a user who
installed the package can start using the shared library
immediately. This line should immediately follow the line
for the shared library itself, as in:</para>
<programlisting>
lib/libtcl80.so.1.0
@exec /sbin/ldconfig -m %D/lib</programlisting>
<para>Never, ever, <emphasis>ever</emphasis> add a line that
says <command>ldconfig</command> without any
arguments to your <filename>Makefile</filename> or <filename>pkg/PLIST</filename>. This will reset the
shared library cache to the contents of
<filename>/usr/lib</filename> only, and will royally screw up
the user's machine (&ldquo;Help, xinit does not run anymore after I
install this port!&rdquo;). Anybody who does this will be shot and
cut into 65,536 pieces by a rusty knife and have his 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)....</para>
</sect4>
<sect4>
<title>UIDs</title>
<para>If your port requires a certain user ID to be on the
installed system, let the <filename>pkg/INSTALL</filename>
script call <command>pw</command> to create it
automatically. Look at <filename>japanese/Wnn</filename> or
<filename>net/cvsup-mirror</filename> for examples. It is
customary to use UIDs in the upper 2-digit range (i.e., from
around 50 to 99) for this purpose.</para>
<para>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.</para>
<programlisting>
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/sh</programlisting>
<para>Please send a notice to &a.ports; if you submit or commit
a port that allocates a new UID in this range so we can keep
this list up to date.</para>
</sect4>
<sect4>
<title>If you are stuck....</title>
<para>Do look at existing examples and the
<filename>bsd.port.mk</filename> file before asking us
questions! <!-- smiley --><emphasis>;)</emphasis></para>
<para>Do ask us questions if you have any trouble! Do not just
beat your head against a wall! <!-- smiley --><emphasis>:)</emphasis></para>
</sect4>
</sect3>
<sect3 id="porting-samplem">
<title>A Sample <filename>Makefile</filename></title>
<para>Here is a sample <filename>Makefile</filename> that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!</para>
<para>It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). Not all of the
existing <filename>Makefile</filename>s are in this format
(mostly old ones), but we are trying to uniformize how they
look. This format is designed so that the most important
information is easy to locate.</para>
<programlisting>
[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 &lt;asami@FreeBSD.ORG&gt;
#
# &#36;Id&#36;
[ ^^^^ 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\\.4\\.:${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 &lt;bsd.port.mk&gt;</programlisting>
</sect3>
<sect3>
<title>Package Names</title>
<para>The 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!</para>
<para>The package name should look like <filename><replaceable>language-</replaceable>name<replaceable>-compiled.specifics</replaceable><replaceable>-version.numbers</replaceable></filename>.</para>
<para>If your <makevar>DISTNAME</makevar>
doesn't look like that, set <makevar>PKGNAME</makevar> to something in that
format.</para>
<orderedlist>
<listitem>
<para>FreeBSD strives to support the native language of its
users. The <replaceable>language-</replaceable> 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
<literal>ja</literal> for Japanese, <literal>ru</literal> for Russian, <literal>vi</literal> for Vietnamese,
<literal>zh</literal> for Chinese, <literal>ko</literal> for Korean and <literal>de</literal> for German.</para>
</listitem>
<listitem>
<para>The <filename>name</filename> 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 package 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 software in question really is called
that way, you can have numbers, hyphens and underscores in
the name too (like <literal>kinput2</literal>).</para>
</listitem>
<listitem>
<para>If the port can be built with different hardcoded
defaults (usually specified as environment variables or on
the <command>make</command> command line), the
<replaceable>-compiled.specifics</replaceable> part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.</para>
</listitem>
<listitem>
<para>The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string <literal>pl</literal> (meaning `patchlevel'), which
can be used <emphasis>only</emphasis> when there are no
major and minor version numbers in the software.</para>
</listitem>
</orderedlist>
<para>Here are some (real) examples on how to convert a <makevar>DISTNAME</makevar> into a suitable <makevar>PKGNAME</makevar>:</para>
<informaltable frame="none">
<tgroup cols="3">
<thead>
<row>
<entry>Distribution Name</entry>
<entry>Package Name</entry>
<entry>Reason</entry>
</row>
</thead>
<tbody>
<row>
<entry>mule-2.2.2.</entry>
<entry>mule-2.2.2</entry>
<entry>No changes required</entry>
</row>
<row>
<entry>XFree86-3.1.2</entry>
<entry>XFree86-3.1.2</entry>
<entry>No changes required</entry>
</row>
<row>
<entry>EmiClock-1.0.2</entry>
<entry>emiclock-1.0.2</entry>
<entry>No uppercase names for single programs</entry>
</row>
<row>
<entry>gmod1.4</entry>
<entry>gmod-1.4</entry>
<entry>Need a hyphen before version numbers</entry>
</row>
<row>
<entry>xmris.4.0.2</entry>
<entry>xmris-4.0.2</entry>
<entry>Need a hyphen before version numbers</entry>
</row>
<row>
<entry>rdist-1.3alpha</entry>
<entry>rdist-1.3a</entry>
<entry>No strings like <literal>alpha</literal>
allowed</entry>
</row>
<row>
<entry>es-0.9-beta1</entry>
<entry>es-0.9b1</entry>
<entry>No strings like <literal>beta</literal>
allowed</entry>
</row>
<row>
<entry>v3.3beta021.src</entry>
<entry>tiff-3.3</entry>
<entry>What the heck was that anyway?</entry>
</row>
<row>
<entry>tvtwm</entry>
<entry>tvtwm-pl11</entry>
<entry>Version string always required</entry>
</row>
<row>
<entry>piewm</entry>
<entry>piewm-1.0</entry>
<entry>Version string always required</entry>
</row>
<row>
<entry>xvgr-2.10pl1</entry>
<entry>xvgr-2.10.1</entry>
<entry><literal>pl</literal> allowed only when no
major/minor version numbers</entry>
</row>
<row>
<entry>gawk-2.15.6</entry>
<entry>ja-gawk-2.15.6</entry>
<entry>Japanese language version</entry>
</row>
<row>
<entry>psutils-1.13</entry>
<entry>psutils-letter-1.13</entry>
<entry>Papersize hardcoded at package build time</entry>
</row>
<row>
<entry>pkfonts</entry>
<entry>pkfonts300-1.0</entry>
<entry>Package for 300dpi fonts</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>If 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 <literal>1.0</literal> (like the piewm example above). Otherwise, ask the
original author or use the date string (<literal><replaceable>yy</replaceable>.<replaceable>mm</replaceable>.<replaceable>dd</replaceable></literal>) as the
version.</para>
</sect3>
<sect3>
<title>That is It, Folks!</title>
<para>Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.</para>
<para>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!
<!-- smiley --><emphasis>:)</emphasis></para>
</sect3>
</sect2>
<sect2>
<title>Money, Hardware or Internet access</title>
<para>We 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.</para>
<sect3>
<title>Donating funds</title>
<para>While the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.</para>
<para>FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.davidg; 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.</para>
<para>Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:</para>
<address>
<otheraddr>FreeBSD, Inc.</otheraddr>
<otheraddr>c/o Jordan Hubbard</otheraddr>
<street>4041 Pike Lane, Suite F</street>
<city>Concord</city>
<state>CA</state>, <postcode>94520</postcode>
</address>
<para>Wire transfers may also be sent directly to:</para>
<address>
<otheraddr>Bank Of America</otheraddr>
<otheraddr>Concord Main Office</otheraddr>
<pob>P.O. Box 37176</pob>
<city>San Francisco</city>
<state>CA</state>, <postcode>94137-5176</postcode>
<otheraddr>Routing #: 121-000-358</otheraddr>
<otheraddr>Account #: 01411-07441 (FreeBSD, Inc.)</otheraddr>
</address>
<para>Any correspondence related to donations should be sent to
Jordan Hubbard <email>jkh@FreeBSD.org</email>,
either via email or to the FreeBSD, Inc. postal address given
above.</para>
<para>If you do not wish to be listed in our <link
linkend="donors">donors</link> section, please specify this
when making your donation. Thanks!</para>
</sect3>
<sect3>
<title>Donating hardware</title>
<para>Donations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:</para>
<itemizedlist>
<listitem>
<para>General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the <emphasis>donating funds</emphasis>
section.</para>
</listitem>
<listitem>
<para>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.davidg; for information on
which items are still required.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Donating Internet access</title>
<para>We can always use new mirror sites for FTP, WWW or <command>cvsup</command>. If
you would like to be such a mirror, please contact the FreeBSD project
administrators <email>admin@FreeBSD.ORG</email> for more information.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="donors">
<title>Donors Gallery</title>
<para>The FreeBSD Project is indebted to the following donors and
would like to publically thank them here!</para>
<itemizedlist>
<listitem>
<para><emphasis>Contributors to the central server
project:</emphasis></para>
<para>The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
<hostid role="fqdn">freefall.freebsd.org</hostid> by donating the
following items:</para>
<itemizedlist>
<listitem>
<para>Ade
Barkah <email>mbarkah@freebsd.org</email> and his employer, <ulink
URL="http://www.hemi.com">Hemisphere Online</ulink>,
donated a <emphasis>Pentium Pro (P6) 200Mhz
CPU</emphasis></para>
</listitem>
<listitem>
<para><ulink URL="http://www.asacomputers.com">ASA
Computers</ulink> donated a <emphasis>Tyan
1662 motherboard</emphasis>.</para>
</listitem>
<listitem>
<para>Joe McGuckin <email>joe@via.net</email>
of <ulink URL="http://www.via.net">ViaNet
Communications</ulink> donated a <emphasis>Kingston ethernet controller.</emphasis></para>
</listitem>
<listitem>
<para>Jack
O'Neill <email>jack@diamond.xtalwind.net</email> donated an <emphasis>NCR
53C875 SCSI controller card</emphasis>.</para>
</listitem>
<listitem>
<para>Ulf
Zimmermann <email>ulf@Alameda.net</email> of <ulink
URL="http://www.Alameda.net">Alameda Networks</ulink>
donated <emphasis>128MB of memory</emphasis>, a
<emphasis>4 Gb disk drive and the
case.</emphasis></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Direct funding:</emphasis></para>
<para>The following individuals and businesses have generously
contributed direct funding to the project:</para>
<itemizedlist>
<listitem>
<para>Annelise
Anderson <email>ANDRSN@HOOVER.STANFORD.EDU</email></para>
</listitem>
<listitem>
<para>Matt
Dillon <email>dillon@best.net</email></para>
</listitem>
<listitem>
<para><ulink URL="http://www.epilogue.com/">Epilogue
Technology Corporation</ulink></para>
</listitem>
<listitem>
<para>Sean Eric Fagan</para>
</listitem>
<listitem>
<para>Gianmarco
Giovannelli <email>gmarco@masternet.it</email></para>
</listitem>
<listitem>
<para>Josef C.
Grosch <email>joeg@truenorth.org</email></para>
</listitem>
<listitem>
<para>Chuck
Robey <email>chuckr@freebsd.org</email></para>
</listitem>
<listitem>
<para>Kenneth
P. Stox <email>ken@stox.sa.enteract.com</email> of <ulink
URL="http://www.imagescape.com">Imaginary Landscape,
LLC.</ulink></para>
</listitem>
<listitem>
<para>Dmitry S.
Kohmanyuk <email>dk@dog.farm.org</email></para>
</listitem>
<listitem>
<para><ulink URL="http://www.cdrom.co.jp/">Laser5</ulink>
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.</para>
</listitem>
<listitem>
<para><ulink URL="http://www.mmjp.or.jp/fuki/">Fuki
Shuppan Publishing Co.</ulink> donated a portion of
their profits from <emphasis>Hajimete no
FreeBSD</emphasis> (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.</para>
</listitem>
<listitem>
<para><ulink URL="http://www.ascii.co.jp/">ASCII
Corp.</ulink> donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.</para>
</listitem>
<listitem>
<para><ulink URL="http://www.yokogawa.co.jp/">Yokogawa
Electric Corp</ulink> has generously donated
significant funding to the FreeBSD project.</para>
</listitem>
<listitem>
<para><ulink
URL="http://www.buffnet.net/">BuffNET</ulink></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Hardware contributors:</emphasis></para>
<para>The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:</para>
<itemizedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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!</para>
</listitem>
<listitem>
<para>Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.</para>
</listitem>
<listitem>
<para>&a.chuck; contributed his floppy tape streamer for
experimental work.</para>
</listitem>
<listitem>
<para>Larry Altneu <email>larry@ALR.COM</email>, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the <devicename>wt</devicename> driver.</para>
</listitem>
<listitem>
<para>Ernst Winter <email>ewinter@lobo.muc.de</email> contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. <!-- smiley -->;-)</para>
</listitem>
<listitem>
<para><ulink URL="http://www.tekram.com">Tekram
Technologies</ulink> 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 <ulink
URL="ftp://ftp.tekram.com/scsi/FreeBSD">ftp://ftp.tekram.com/scsi/FreeBSD</ulink>.</para>
</listitem>
<listitem>
<para><email>Larry M.
Augustin</email> 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!</para>
</listitem>
<listitem>
<para>Christoph
Kukulies <email>kuku@freebsd.org</email> donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Special contributors:</emphasis></para>
<itemizedlist>
<listitem>
<para><ulink URL="http://www.cdrom.com">Walnut Creek
CDROM</ulink> has donated almost more than we can say
(see the
<link linkend="history">history</link> document for
more details). In particular, we would like to thank
them for the original hardware used for
<hostid role="fqdn">freefall.FreeBSD.ORG</hostid>, our primary
development machine, and for
<hostid role="fqdn">thud.FreeBSD.ORG</hostid>, 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.</para>
</listitem>
<listitem>
<para>The <ulink
URL="http://www.interface-business.de">interface
business GmbH, Dresden</ulink> 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...</para>
</listitem>
<listitem>
<para><ulink URL="http://www.bsdi.com">Berkeley Software
Design, Inc.</ulink> has contributed their DOS
emulator code to the remaining BSD world, which is used
in the <emphasis>dosemu</emphasis> command.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect1>
<sect1>
<title>Derived Software Contributors</title>
<para>This 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.</para>
<para>There are also portions of NetBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD for their work.</para>
</sect1>
<sect1 id="contrib-additional">
<title>Additional FreeBSD Contributors</title>
<para>(in alphabetical order by first name):</para>
<itemizedlist>
<listitem>
<para>A JOSEPH KOSHY <email>koshy@india.hp.com</email></para>
</listitem>
<listitem>
<para>ABURAYA Ryushirou <email>rewsirow@ff.iij4u.or.jp</email></para>
</listitem>
<listitem>
<para>Ada T Lim <email>ada@bsd.org</email></para>
</listitem>
<listitem>
<para>Adam Glass <email>glass@postgres.berkeley.edu</email></para>
</listitem>
<listitem>
<para>Adrian T. Filipi-Martin <email>atf3r@agate.cs.virginia.edu</email></para>
</listitem>
<listitem>
<para>Akito Fujita <email>fujita@zoo.ncl.omron.co.jp</email></para>
</listitem>
<listitem>
<para>Alain Kalker <email>A.C.P.M.Kalker@student.utwente.nl</email></para>
</listitem>
<listitem>
<para>Alan Cox <email>alc@cs.rice.edu</email></para>
</listitem>
<listitem>
<para>Andreas Kohout <email>shanee@rabbit.augusta.de</email></para>
</listitem>
<listitem>
<para>Andreas Lohr <email>andreas@marvin.RoBIN.de</email></para>
</listitem>
<listitem>
<para>Andrew Gordon <email>andrew.gordon@net-tel.co.uk</email></para>
</listitem>
<listitem>
<para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para>
</listitem>
<listitem>
<para>Andrew McRae <email>amcrae@cisco.com</email></para>
</listitem>
<listitem>
<para>Andrew Moore <email>alm@FreeBSD.org</email></para>
</listitem>
<listitem>
<para>Andrew Stevenson <email>andrew@ugh.net.au</email></para>
</listitem>
<listitem>
<para>Andrew V. Stesin <email>stesin@elvisti.kiev.ua</email></para>
</listitem>
<listitem>
<para>Andrey Zakhvatov <email>andy@icc.surw.chel.su</email></para>
</listitem>
<listitem>
<para>Andy Whitcroft <email>andy@sarc.city.ac.uk</email></para>
</listitem>
<listitem>
<para>Angelo Turetta <email>ATuretta@stylo.it</email></para>
</listitem>
<listitem>
<para>Anthony Yee-Hang Chan <email>yeehang@netcom.com</email></para>
</listitem>
<listitem>
<para>Ari Suutari <email>ari@suutari.iki.fi</email></para>
</listitem>
<listitem>
<para>Brent J. Nordquist <email>bjn@visi.com</email></para>
</listitem>
<listitem>
<para>Bernd Rosauer <email>br@schiele-ct.de</email></para>
</listitem>
<listitem>
<para>Bill Kish <email>kish@osf.org</email></para>
</listitem>
<listitem>
<para>&a.wlloyd;</para>
</listitem>
<listitem>
<para>Bob Wilcox <email>bob@obiwan.uucp</email></para>
</listitem>
<listitem>
<para>Boyd Faulkner <email>faulkner@mpd.tandem.com</email></para>
</listitem>
<listitem>
<para>Brent J. Nordquist <email>bjn@visi.com</email></para>
</listitem>
<listitem>
<para>Brett Taylor <email>brett@peloton.physics.montana.edu</email></para>
</listitem>
<listitem>
<para>Brian Clapper <email>bmc@willscreek.com</email></para>
</listitem>
<listitem>
<para>Brian Handy <email>handy@lambic.space.lockheed.com</email></para>
</listitem>
<listitem>
<para>Brian Tao <email>taob@risc.org</email></para>
</listitem>
<listitem>
<para>Brion Moss <email>brion@queeg.com</email></para>
</listitem>
<listitem>
<para>Bruce Gingery <email>bgingery@gtcs.com</email></para>
</listitem>
<listitem>
<para>Carey Jones <email>mcj@acquiesce.org</email></para>
</listitem>
<listitem>
<para>Carl Fongheiser <email>cmf@netins.net</email></para>
</listitem>
<listitem>
<para>Charles Hannum <email>mycroft@ai.mit.edu</email></para>
</listitem>
<listitem>
<para>Charles Mott <email>cmott@srv.net</email></para>
</listitem>
<listitem>
<para>Chet Ramey <email>chet@odin.INS.CWRU.Edu</email></para>
</listitem>
<listitem>
<para>Chris Dabrowski <email>chris@vader.org</email></para>
</listitem>
<listitem>
<para>Chris G. Demetriou <email>cgd@postgres.berkeley.edu</email></para>
</listitem>
<listitem>
<para>Chris Shenton <email>cshenton@angst.it.hq.nasa.gov</email></para>
</listitem>
<listitem>
<para>Chris Stenton <email>jacs@gnome.co.uk</email></para>
</listitem>
<listitem>
<para>Chris Timmons <email>skynyrd@opus.cts.cwu.edu</email></para>
</listitem>
<listitem>
<para>Chris Torek <email>torek@ee.lbl.gov</email></para>
</listitem>
<listitem>
<para>Christian Gusenbauer <email>cg@fimp01.fim.uni-linz.ac.at</email></para>
</listitem>
<listitem>
<para>Christian Haury <email>Christian.Haury@sagem.fr</email></para>
</listitem>
<listitem>
<para>Christoph Robitschko <email>chmr@edvz.tu-graz.ac.at</email></para>
</listitem>
<listitem>
<para>Choi Jun Ho <email>junker@jazz.snu.ac.kr</email></para>
</listitem>
<listitem>
<para>Chuck Hein <email>chein@cisco.com</email></para>
</listitem>
<listitem>
<para>Conrad Sabatier <email>conrads@neosoft.com</email></para>
</listitem>
<listitem>
<para>Cornelis van der Laan <email>nils@guru.ims.uni-stuttgart.de</email></para>
</listitem>
<listitem>
<para>Craig Struble <email>cstruble@vt.edu</email></para>
</listitem>
<listitem>
<para>Cristian Ferretti <email>cfs@riemann.mat.puc.cl</email></para>
</listitem>
<listitem>
<para>Curt Mayer <email>curt@toad.com</email></para>
</listitem>
<listitem>
<para>Dai Ishijima <email>ishijima@tri.pref.osaka.jp</email></para>
</listitem>
<listitem>
<para>Dan Cross <email>tenser@spitfire.ecsel.psu.edu</email></para>
</listitem>
<listitem>
<para>Daniel Baker <email>dbaker@crash.ops.neosoft.com</email></para>
</listitem>
<listitem>
<para>Daniel M. Eischen <email>deischen@iworks.InterWorks.org</email></para>
</listitem>
<listitem>
<para>Daniel O'Connor <email>doconnor@gsoft.com.au</email></para>
</listitem>
<listitem>
<para>Danny J. Zerkel <email>dzerkel@feephi.phofarm.com</email></para>
</listitem>
<listitem>
<para>Dave Bodenstab <email>imdave@synet.net</email></para>
</listitem>
<listitem>
<para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para>
</listitem>
<listitem>
<para>Dave Chapeskie <email>dchapes@zeus.leitch.com</email></para>
</listitem>
<listitem>
<para>Dave Edmondson <email>davided@sco.com</email></para>
</listitem>
<listitem>
<para>Dave Rivers <email>rivers@ponds.uucp</email></para>
</listitem>
<listitem>
<para>David A. Bader <email>dbader@umiacs.umd.edu</email></para>
</listitem>
<listitem>
<para>David Dawes <email>dawes@physics.su.OZ.AU</email></para>
</listitem>
<listitem>
<para>David Holloway <email>daveh@gwythaint.tamis.com</email></para>
</listitem>
<listitem>
<para>David Leonard <email>d@scry.dstc.edu.au</email></para>
</listitem>
<listitem>
<para>Dean Huxley <email>dean@fsa.ca</email></para>
</listitem>
<listitem>
<para>Dirk Froemberg <email>dirk@hal.in-berlin.de</email></para>
</listitem>
<listitem>
<para>Dmitrij Tejblum <email>dima@tejblum.dnttm.rssi.ru</email></para>
</listitem>
<listitem>
<para>Dmitry Kohmanyuk <email>dk@farm.org</email></para>
</listitem>
<listitem>
<para>&a.whiteside;</para>
</listitem>
<listitem>
<para>Don Yuniskis <email>dgy@rtd.com</email></para>
</listitem>
<listitem>
<para>Donald Burr <email>d_burr@ix.netcom.com</email></para>
</listitem>
<listitem>
<para>Doug Ambrisko <email>ambrisko@ambrisko.roble.com</email></para>
</listitem>
<listitem>
<para>Douglas Carmichael <email>dcarmich@mcs.com</email></para>
</listitem>
<listitem>
<para>Eiji-usagi-MATSUmoto <email>usagi@ruby.club.or.jp</email></para>
</listitem>
<listitem>
<para>ELISA Font Project</para>
</listitem>
<listitem>
<para>Eric A. Griff <email>eagriff@global2000.net</email></para>
</listitem>
<listitem>
<para>Eric Blood <email>eblood@cs.unr.edu</email></para>
</listitem>
<listitem>
<para>Eric J. Chet <email>ejc@bazzle.com</email></para>
</listitem>
<listitem>
<para>Eric J. Schwertfeger <email>eric@cybernut.com</email></para>
</listitem>
<listitem>
<para>Francis M J Hsieh <email>mjhsieh@life.nthu.edu.tw</email></para>
</listitem>
<listitem>
<para>Frank Bartels <email>knarf@camelot.de</email></para>
</listitem>
<listitem>
<para>Frank Chen Hsiung Chan <email>frankch@waru.life.nthu.edu.tw</email></para>
</listitem>
<listitem>
<para>Frank Maclachlan <email>fpm@crash.cts.com</email></para>
</listitem>
<listitem>
<para>Frank Nobis <email>fn@trinity.radio-do.de</email></para>
</listitem>
<listitem>
<para>FUJIMOTO Kensaku <email>fujimoto@oscar.elec.waseda.ac.jp</email></para>
</listitem>
<listitem>
<para>FURUSAWA Kazuhisa <email>furusawa@com.cs.osakafu-u.ac.jp</email></para>
</listitem>
<listitem>
<para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para>
</listitem>
<listitem>
<para>Gary Kline <email>kline@thought.org</email></para>
</listitem>
<listitem>
<para>Gerard Roudier <email>groudier@club-internet.fr</email></para>
</listitem>
<listitem>
<para>Greg Ungerer <email>gerg@stallion.oz.au</email></para>
</listitem>
<listitem>
<para>Harlan Stenn <email>Harlan.Stenn@pfcs.com</email></para>
</listitem>
<listitem>
<para>Havard Eidnes <email>Havard.Eidnes@runit.sintef.no</email></para>
</listitem>
<listitem>
<para>Hideaki Ohmon <email>ohmon@tom.sfc.keio.ac.jp</email></para>
</listitem>
<listitem>
<para>Hidekazu Kuroki <email>hidekazu@cs.titech.ac.jp</email></para>
</listitem>
<listitem>
<para>Hidetoshi Shimokawa <email>simokawa@sat.t.u-tokyo.ac.jp</email></para>
</listitem>
<listitem>
<para>Hideyuki Suzuki <email>hideyuki@sat.t.u-tokyo.ac.jp</email></para>
</listitem>
<listitem>
<para>Hironori Ikura <email>hikura@kaisei.org</email></para>
</listitem>
<listitem>
<para>Holger Veit <email>Holger.Veit@gmd.de</email></para>
</listitem>
<listitem>
<para>Hung-Chi Chu <email>hcchu@r350.ee.ntu.edu.tw</email></para>
</listitem>
<listitem>
<para>Ian Vaudrey <email>i.vaudrey@bigfoot.com</email></para>
</listitem>
<listitem>
<para>Igor Vinokurov <email>igor@zynaps.ru</email></para>
</listitem>
<listitem>
<para>Ikuo Nakagawa <email>ikuo@isl.intec.co.jp</email></para>
</listitem>
<listitem>
<para>IMAMURA Tomoaki <email>tomoak-i@is.aist-nara.ac.jp</email></para>
</listitem>
<listitem>
<para>Ishii Masahiro</para>
</listitem>
<listitem>
<para>Issei Suzuki <email>issei@t-cnet.or.jp</email></para>
</listitem>
<listitem>
<para>Itsuro Saito <email>saito@miv.t.u-tokyo.ac.jp</email></para>
</listitem>
<listitem>
<para>J. David Lowe <email>lowe@saturn5.com</email></para>
</listitem>
<listitem>
<para>J.T. Conklin <email>jtc@cygnus.com</email></para>
</listitem>
<listitem>
<para>James Clark <email>jjc@jclark.com</email></para>
</listitem>
<listitem>
<para>James da Silva <email>jds@cs.umd.edu</email> et al</para>
</listitem>
<listitem>
<para>Janusz Kokot <email>janek@gaja.ipan.lublin.pl</email></para>
</listitem>
<listitem>
<para>Jason Thorpe <email>thorpej@nas.nasa.gov</email></para>
</listitem>
<listitem>
<para>Javier Martin Rueda <email>jmrueda@diatel.upm.es</email></para>
</listitem>
<listitem>
<para>Jeff Bartig <email>jeffb@doit.wisc.edu</email></para>
</listitem>
<listitem>
<para>Jeffrey Wheat <email>jeff@cetlink.net</email></para>
</listitem>
<listitem>
<para>Jian-Da Li <email>jdli@csie.NCTU.edu.tw</email></para>
</listitem>
<listitem>
<para>Jim Binkley <email>jrb@cs.pdx.edu</email></para>
</listitem>
<listitem>
<para>Jim Lowe <email>james@cs.uwm.edu</email></para>
</listitem>
<listitem>
<para>Jim Wilson <email>wilson@moria.cygnus.com</email></para>
</listitem>
<listitem>
<para>Joao Carlos Mendes Luis <email>jonny@coppe.ufrj.br</email></para>
</listitem>
<listitem>
<para>Joel Sutton <email>sutton@aardvark.apana.org.au</email></para>
</listitem>
<listitem>
<para>Johann Tonsing <email>jtonsing@mikom.csir.co.za</email></para>
</listitem>
<listitem>
<para>John Capo <email>jc@irbs.com</email></para>
</listitem>
<listitem>
<para>John Heidemann <email>johnh@isi.edu</email></para>
</listitem>
<listitem>
<para>John Perry <email>perry@vishnu.alias.net</email></para>
</listitem>
<listitem>
<para>John Polstra <email>jdp@polstra.com</email></para>
</listitem>
<listitem>
<para>John Rochester <email>jr@cs.mun.ca</email></para>
</listitem>
<listitem>
<para>Josef Karthauser <email>joe@uk.freebsd.org</email></para>
</listitem>
<listitem>
<para>Joseph Stein <email>joes@seaport.net</email></para>
</listitem>
<listitem>
<para>Josh Gilliam <email>josh@quick.net</email></para>
</listitem>
<listitem>
<para>Josh Tiefenbach <email>josh@ican.net</email></para>
</listitem>
<listitem>
<para>Juergen Lock <email>nox@jelal.hb.north.de</email></para>
</listitem>
<listitem>
<para>Juha Inkari <email>inkari@cc.hut.fi</email></para>
</listitem>
<listitem>
<para>Julian Assange <email>proff@suburbia.net</email></para>
</listitem>
<listitem>
<para>Julian Jenkins <email>kaveman@magna.com.au</email></para>
</listitem>
<listitem>
<para>Julian Stacey <email>jhs@freebsd.org</email></para>
</listitem>
<listitem>
<para>Junichi Satoh <email>junichi@jp.freebsd.org</email></para>
</listitem>
<listitem>
<para>Kapil Chowksey <email>kchowksey@hss.hns.com</email></para>
</listitem>
<listitem>
<para>Kazuhiko Kiriyama <email>kiri@kiri.toba-cmt.ac.jp</email></para>
</listitem>
<listitem>
<para>Keith Bostic <email>bostic@bostic.com</email></para>
</listitem>
<listitem>
<para>Keith Moore</para>
</listitem>
<listitem>
<para>Kenneth Monville <email>desmo@bandwidth.org</email></para>
</listitem>
<listitem>
<para>Kent Vander Velden <email>graphix@iastate.edu</email></para>
</listitem>
<listitem>
<para>Kirk McKusick <email>mckusick@mckusick.com</email></para>
</listitem>
<listitem>
<para>Kiroh HARADA <email>kiroh@kh.rim.or.jp</email></para>
</listitem>
<listitem>
<para>Koichi Sato <email>copan@ppp.fastnet.or.jp</email></para>
</listitem>
<listitem>
<para>Kostya Lukin <email>lukin@okbmei.msk.su</email></para>
</listitem>
<listitem>
<para>Kurt Olsen <email>kurto@tiny.mcs.usu.edu</email></para>
</listitem>
<listitem>
<para>Lars Koeller <email>Lars.Koeller@Uni-Bielefeld.DE</email></para>
</listitem>
<listitem>
<para>Lucas James <email>Lucas.James@ldjpc.apana.org.au</email></para>
</listitem>
<listitem>
<para>Luigi Rizzo <email>luigi@iet.unipi.it</email></para>
</listitem>
<listitem>
<para>Makoto MATSUSHITA <email>matusita@jp.freebsd.org</email></para>
</listitem>
<listitem>
<para>Manu Iyengar <email>iyengar@grunthos.pscwa.psca.com</email></para>
</listitem>
<listitem>
<para>Marc Frajola <email>marc@dev.com</email></para>
</listitem>
<listitem>
<para>Marc Ramirez <email>mrami@mramirez.sy.yale.edu</email></para>
</listitem>
<listitem>
<para>Marc Slemko <email>marcs@znep.com</email></para>
</listitem>
<listitem>
<para>Marc van Kempen <email>wmbfmk@urc.tue.nl</email></para>
</listitem>
<listitem>
<para>Mario Sergio Fujikawa Ferreira <email>lioux@gns.com.br</email></para>
</listitem>
<listitem>
<para>Mark Huizer <email>xaa@stack.nl</email></para>
</listitem>
<listitem>
<para>Mark J. Taylor <email>mtaylor@cybernet.com</email></para>
</listitem>
<listitem>
<para>Mark Krentel <email>krentel@rice.edu</email></para>
</listitem>
<listitem>
<para>Mark Tinguely <email>tinguely@plains.nodak.edu</email> <email>tinguely@hookie.cs.ndsu.NoDak.edu</email></para>
</listitem>
<listitem>
<para>Martin Birgmeier</para>
</listitem>
<listitem>
<para>Martti Kuparinen <email>erakupa@kk.etx.ericsson.se</email></para>
</listitem>
<listitem>
<para>Masachika ISHIZUKA <email>ishizuka@isis.min.ntt.jp</email></para>
</listitem>
<listitem>
<para>Mats Lofkvist <email>mal@algonet.se</email></para>
</listitem>
<listitem>
<para>Matt Bartley <email>mbartley@lear35.cytex.com</email></para>
</listitem>
<listitem>
<para>Matt Thomas <email>thomas@lkg.dec.com</email></para>
</listitem>
<listitem>
<para>Matt White <email>mwhite+@CMU.EDU</email></para>
</listitem>
<listitem>
<para>Matthew Hunt <email>mph@pobox.com</email></para>
</listitem>
<listitem>
<para>Matthew N. Dodd <email>winter@jurai.net</email></para>
</listitem>
<listitem>
<para>Matthew Stein <email>matt@bdd.net</email></para>
</listitem>
<listitem>
<para>Maurice Castro <email>maurice@planet.serc.rmit.edu.au</email></para>
</listitem>
<listitem>
<para>Michael Butschky <email>butsch@computi.erols.com</email></para>
</listitem>
<listitem>
<para>Michael Elbel <email>me@FreeBSD.ORG</email></para>
</listitem>
<listitem>
<para>Michael Searle <email>searle@longacre.demon.co.uk</email></para>
</listitem>
<listitem>
<para>Miguel Angel Sagreras <email>msagre@cactus.fi.uba.ar</email></para>
</listitem>
<listitem>
<para>Mikael Hybsch <email>micke@dynas.se</email></para>
</listitem>
<listitem>
<para>Mikhail Teterin <email>mi@aldan.ziplink.net</email></para>
</listitem>
<listitem>
<para>Mike McGaughey <email>mmcg@cs.monash.edu.au</email></para>
</listitem>
<listitem>
<para>Mike Peck <email>mike@binghamton.edu</email></para>
</listitem>
<listitem>
<para>Ming-I Hseh <email>PA@FreeBSD.ee.Ntu.edu.TW</email></para>
</listitem>
<listitem>
<para>MITA Yoshio <email>mita@jp.FreeBSD.ORG</email></para>
</listitem>
<listitem>
<para>MOROHOSHI Akihiko <email>moro@race.u-tokyo.ac.jp</email></para>
</listitem>
<listitem>
<para>Murray Stokely <email>murray@cdrom.com</email></para>
</listitem>
<listitem>
<para>NAKAMURA Kazushi <email>nkazushi@highway.or.jp</email></para>
</listitem>
<listitem>
<para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para>
</listitem>
<listitem>
<para>Narvi <email>narvi@haldjas.folklore.ee</email></para>
</listitem>
<listitem>
<para>NIIMI Satoshi <email>sa2c@and.or.jp</email></para>
</listitem>
<listitem>
<para>Nick Sayer <email>nsayer@quack.kfu.com</email></para>
</listitem>
<listitem>
<para>Nicolas Souchu <email>Nicolas.Souchu@prism.uvsq.fr</email></para>
</listitem>
<listitem>
<para>Nisha Talagala <email>nisha@cs.berkeley.edu</email></para>
</listitem>
<listitem>
<para>Nobuhiro Yasutomi <email>nobu@psrc.isac.co.jp</email></para>
</listitem>
<listitem>
<para>Nobuyuki Koganemaru <email>kogane@kces.koganemaru.co.jp</email></para>
</listitem>
<listitem>
<para>Noritaka Ishizumi <email>graphite@jp.FreeBSD.ORG</email></para>
</listitem>
<listitem>
<para>Oliver Fromme <email>oliver.fromme@heim3.tu-clausthal.de</email></para>
</listitem>
<listitem>
<para>Oliver Laumann <email>net@informatik.uni-bremen.de</email></para>
</listitem>
<listitem>
<para>Oliver Oberdorf <email>oly@world.std.com</email></para>
</listitem>
<listitem>
<para>Paul Fox <email>pgf@foxharp.boston.ma.us</email></para>
</listitem>
<listitem>
<para>Paul Kranenburg <email>pk@cs.few.eur.nl</email></para>
</listitem>
<listitem>
<para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para>
</listitem>
<listitem>
<para>Paulo Menezes <email>paulo@isr.uc.pt</email></para>
</listitem>
<listitem>
<para>Paul T. Root <email>proot@horton.iaces.com</email></para>
</listitem>
<listitem>
<para>Pedro Giffuni <email>giffunip@asme.org</email></para>
</listitem>
<listitem>
<para>Pedro A M Vazquez <email>vazquez@IQM.Unicamp.BR</email></para>
</listitem>
<listitem>
<para>Peter Cornelius <email>pc@inr.fzk.de</email></para>
</listitem>
<listitem>
<para>Peter Haight <email>peterh@prognet.com</email></para>
</listitem>
<listitem>
<para>Peter Hawkins <email>peter@rhiannon.clari.net.au</email></para>
</listitem>
<listitem>
<para>Peter Stubbs <email>PETERS@staidan.qld.edu.au</email></para>
</listitem>
<listitem>
<para>Pierre Beyssac <email>bp@fasterix.freenix.org</email></para>
</listitem>
<listitem>
<para>Phil Maker <email>pjm@cs.ntu.edu.au</email></para>
</listitem>
<listitem>
<para>R. Kym Horsell</para>
</listitem>
<listitem>
<para>Randall Hopper <email>rhh@stealth.ct.picker.com</email></para>
</listitem>
<listitem>
<para>Richard Hwang <email>rhwang@bigpanda.com</email></para>
</listitem>
<listitem>
<para>Richard Seaman, Jr. <email>dick@tar.com</email></para>
</listitem>
<listitem>
<para>Richard Stallman <email>rms@gnu.ai.mit.edu</email></para>
</listitem>
<listitem>
<para>Richard Wiwatowski <email>rjwiwat@adelaide.on.net</email></para>
</listitem>
<listitem>
<para>Rob Mallory <email>rmallory@csusb.edu</email></para>
</listitem>
<listitem>
<para>Rob Shady <email>rls@id.net</email></para>
</listitem>
<listitem>
<para>Rob Snow <email>rsnow@txdirect.net</email></para>
</listitem>
<listitem>
<para>Robert Sanders <email>rsanders@mindspring.com</email></para>
</listitem>
<listitem>
<para>Robert Withrow <email>witr@rwwa.com</email></para>
</listitem>
<listitem>
<para>Ronald Kuehn <email>kuehn@rz.tu-clausthal.de</email></para>
</listitem>
<listitem>
<para>Roland Jesse <email>jesse@cs.uni-magdeburg.de</email></para>
</listitem>
<listitem>
<para>Ruslan Shevchenko <email>rssh@cki.ipri.kiev.ua</email></para>
</listitem>
<listitem>
<para>Samuel Lam <email>skl@ScalableNetwork.com</email></para>
</listitem>
<listitem>
<para>Sander Vesik <email>sander@haldjas.folklore.ee</email></para>
</listitem>
<listitem>
<para>Sandro Sigala <email>ssigala@globalnet.it</email></para>
</listitem>
<listitem>
<para>Sascha Blank <email>blank@fox.uni-trier.de</email></para>
</listitem>
<listitem>
<para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para>
</listitem>
<listitem>
<para>Satoshi Taoka <email>taoka@infonets.hiroshima-u.ac.jp</email></para>
</listitem>
<listitem>
<para>Scott Blachowicz <email>scott.blachowicz@seaslug.org</email></para>
</listitem>
<listitem>
<para>Scott A. Kenney <email>saken@rmta.ml.org</email></para>
</listitem>
<listitem>
<para>Serge V. Vakulenko <email>vak@zebub.msk.su</email></para>
</listitem>
<listitem>
<para>Sheldon Hearn <email>axl@iafrica.com</email></para>
</listitem>
<listitem>
<para>Simon Marlow <email>simonm@dcs.gla.ac.uk</email></para>
</listitem>
<listitem>
<para>Slaven Rezic (Tomic) <email>eserte@cs.tu-berlin.de</email></para>
</listitem>
<listitem>
<para>Soren Dayton <email>csdayton@midway.uchicago.edu</email></para>
</listitem>
<listitem>
<para>Soren Dossing <email>sauber@netcom.com</email></para>
</listitem>
<listitem>
<para>Stefan Moeding <email>moeding@bn.DeTeMobil.de</email></para>
</listitem>
<listitem>
<para>Stephane Legrand <email>stephane@lituus.fr</email></para>
</listitem>
<listitem>
<para>Stephen J. Roznowski <email>sjr@home.net</email></para>
</listitem>
<listitem>
<para>Steve Gerakines <email>steve2@genesis.tiac.net</email></para>
</listitem>
<listitem>
<para>Suzuki Yoshiaki <email>zensyo@ann.tama.kawasaki.jp</email></para>
</listitem>
<listitem>
<para>Tadashi Kumano <email>kumano@strl.nhk.or.jp</email></para>
</listitem>
<listitem>
<para>Taguchi Takeshi <email>taguchi@tohoku.iij.ad.jp</email></para>
</listitem>
<listitem>
<para>Takayuki Ariga <email>a00821@cc.hc.keio.ac.jp</email></para>
</listitem>
<listitem>
<para>Terry Lambert <email>terry@lambert.org</email></para>
</listitem>
<listitem>
<para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para>
</listitem>
<listitem>
<para>Tetsuya Furukawa <email>tetsuya@secom-sis.co.jp</email></para>
</listitem>
<listitem>
<para>Theo Deraadt <email>deraadt@fsa.ca</email></para>
</listitem>
<listitem>
<para>Thomas K&ouml;nig <email>Thomas.Koenig@ciw.uni-karlsruhe.de</email></para>
</listitem>
<listitem>
<para>&THORN;&oacute;r&eth;ur &Iacute;varsson <email>totii@est.is</email></para>
</listitem>
<listitem>
<para>Tim Kientzle <email>kientzle@netcom.com</email></para>
</listitem>
<listitem>
<para>Tim Wilkinson <email>tim@sarc.city.ac.uk</email></para>
</listitem>
<listitem>
<para>Tom Samplonius <email>tom@misery.sdf.com</email></para>
</listitem>
<listitem>
<para>Torbjorn Granlund <email>tege@matematik.su.se</email></para>
</listitem>
<listitem>
<para>Toshihiro Kanda <email>candy@fct.kgc.co.jp</email></para>
</listitem>
<listitem>
<para>Trefor S. <email>trefor@flevel.co.uk</email></para>
</listitem>
<listitem>
<para>Ville Eerola <email>ve@sci.fi</email></para>
</listitem>
<listitem>
<para>Werner Griessl <email>werner@btp1da.phy.uni-bayreuth.de</email></para>
</listitem>
<listitem>
<para>Wes Santee <email>wsantee@wsantee.oz.net</email></para>
</listitem>
<listitem>
<para>Wilko Bulte <email>wilko@yedi.iaf.nl</email></para>
</listitem>
<listitem>
<para>Wolfgang Stanglmeier <email>wolf@kintaro.cologne.de</email></para>
</listitem>
<listitem>
<para>Wu Ching-hong <email>woju@FreeBSD.ee.Ntu.edu.TW</email></para>
</listitem>
<listitem>
<para>Yen-Shuo Su <email>yssu@CCCA.NCTU.edu.tw</email></para>
</listitem>
<listitem>
<para>Yoshiaki Uchikawa <email>yoshiaki@kt.rim.or.jp</email></para>
</listitem>
<listitem>
<para>Yoshiro Mihira <email>sanpei@yy.cs.keio.ac.jp</email></para>
</listitem>
<listitem>
<para>Yukihiro Nakai <email>nakai@mlab.t.u-tokyo.ac.jp</email></para>
</listitem>
<listitem>
<para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para>
</listitem>
<listitem>
<para>Yves Fonk <email>yves@cpcoup5.tn.tudelft.nl</email></para>
</listitem>
</itemizedlist>
</sect1>
<sect1>
<title>386BSD Patch Kit Patch Contributors</title>
<para>(in alphabetical order by first name):</para>
<itemizedlist>
<listitem>
<para>Adam Glass <email>glass@postgres.berkeley.edu</email></para>
</listitem>
<listitem>
<para>Adrian Hall <email>adrian@ibmpcug.co.uk</email></para>
</listitem>
<listitem>
<para>Andrey A. Chernov <email>ache@astral.msk.su</email></para>
</listitem>
<listitem>
<para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para>
</listitem>
<listitem>
<para>Andrew Moore <email>alm@netcom.com</email></para>
</listitem>
<listitem>
<para>Andy Valencia <email>ajv@csd.mot.com</email> <email>jtk@netcom.com</email></para>
</listitem>
<listitem>
<para>Arne Henrik Juul <email>arnej@Lise.Unit.NO</email></para>
</listitem>
<listitem>
<para>Bakul Shah <email>bvs@bitblocks.com</email></para>
</listitem>
<listitem>
<para>Barry Lustig <email>barry@ictv.com</email></para>
</listitem>
<listitem>
<para>Bob Wilcox <email>bob@obiwan.uucp</email></para>
</listitem>
<listitem>
<para>Branko Lankester</para>
</listitem>
<listitem>
<para>Brett Lymn <email>blymn@mulga.awadi.com.AU</email></para>
</listitem>
<listitem>
<para>Charles Hannum <email>mycroft@ai.mit.edu</email></para>
</listitem>
<listitem>
<para>Chris G. Demetriou <email>cgd@postgres.berkeley.edu</email></para>
</listitem>
<listitem>
<para>Chris Torek <email>torek@ee.lbl.gov</email></para>
</listitem>
<listitem>
<para>Christoph Robitschko <email>chmr@edvz.tu-graz.ac.at</email></para>
</listitem>
<listitem>
<para>Daniel Poirot <email>poirot@aio.jsc.nasa.gov</email></para>
</listitem>
<listitem>
<para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para>
</listitem>
<listitem>
<para>Dave Rivers <email>rivers@ponds.uucp</email></para>
</listitem>
<listitem>
<para>David Dawes <email>dawes@physics.su.OZ.AU</email></para>
</listitem>
<listitem>
<para>David Greenman <email>davidg@Root.COM</email></para>
</listitem>
<listitem>
<para>Eric J. Haug <email>ejh@slustl.slu.edu</email></para>
</listitem>
<listitem>
<para>Felix Gaehtgens <email>felix@escape.vsse.in-berlin.de</email></para>
</listitem>
<listitem>
<para>Frank Maclachlan <email>fpm@crash.cts.com</email></para>
</listitem>
<listitem>
<para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para>
</listitem>
<listitem>
<para>Gary Howland <email>gary@hotlava.com</email></para>
</listitem>
<listitem>
<para>Geoff Rehmet <email>csgr@alpha.ru.ac.za</email></para>
</listitem>
<listitem>
<para>Goran Hammarback <email>goran@astro.uu.se</email></para>
</listitem>
<listitem>
<para>Guido van Rooij <email>guido@gvr.win.tue.nl</email></para>
</listitem>
<listitem>
<para>Guy Harris <email>guy@auspex.com</email></para>
</listitem>
<listitem>
<para>Havard Eidnes <email>Havard.Eidnes@runit.sintef.no</email></para>
</listitem>
<listitem>
<para>Herb Peyerl <email>hpeyerl@novatel.cuc.ab.ca</email></para>
</listitem>
<listitem>
<para>Holger Veit <email>Holger.Veit@gmd.de</email></para>
</listitem>
<listitem>
<para>Ishii Masahiro, R. Kym Horsell</para>
</listitem>
<listitem>
<para>J.T. Conklin <email>jtc@cygnus.com</email></para>
</listitem>
<listitem>
<para>Jagane D Sundar <email>jagane@netcom.com</email></para>
</listitem>
<listitem>
<para>James Clark <email>jjc@jclark.com</email></para>
</listitem>
<listitem>
<para>James Jegers <email>jimj@miller.cs.uwm.edu</email></para>
</listitem>
<listitem>
<para>James W. Dolter</para>
</listitem>
<listitem>
<para>James da Silva <email>jds@cs.umd.edu</email> et al</para>
</listitem>
<listitem>
<para>Jay Fenlason <email>hack@datacube.com</email></para>
</listitem>
<listitem>
<para>Jim Wilson <email>wilson@moria.cygnus.com</email></para>
</listitem>
<listitem>
<para>J&ouml;rg Lohse <email>lohse@tech7.informatik.uni-hamburg.de</email></para>
</listitem>
<listitem>
<para>J&ouml;rg Wunsch <email>joerg_wunsch@uriah.heep.sax.de</email></para>
</listitem>
<listitem>
<para>John Dyson <email>formerly
dyson@ref.tfs.com</email></para>
</listitem>
<listitem>
<para>John Woods <email>jfw@eddie.mit.edu</email></para>
</listitem>
<listitem>
<para>Jordan K. Hubbard <email>jkh@whisker.hubbard.ie</email></para>
</listitem>
<listitem>
<para>Julian Elischer <email>julian@dialix.oz.au</email></para>
</listitem>
<listitem>
<para>Julian Stacey <email>jhs@freebsd.org</email></para>
</listitem>
<listitem>
<para>Karl Lehenbauer <email>karl@NeoSoft.com</email> <email>karl@one.neosoft.com</email></para>
</listitem>
<listitem>
<para>Keith Bostic <email>bostic@toe.CS.Berkeley.EDU</email></para>
</listitem>
<listitem>
<para>Ken Hughes</para>
</listitem>
<listitem>
<para>Kent Talarico <email>kent@shipwreck.tsoft.net</email></para>
</listitem>
<listitem>
<para>Kevin Lahey <email>kml%rokkaku.UUCP@mathcs.emory.edu</email> <email>kml@mosquito.cis.ufl.edu</email></para>
</listitem>
<listitem>
<para>Marc Frajola <email>marc@dev.com</email></para>
</listitem>
<listitem>
<para>Mark Tinguely <email>tinguely@plains.nodak.edu</email> <email>tinguely@hookie.cs.ndsu.NoDak.edu</email></para>
</listitem>
<listitem>
<para>Martin Renters <email>martin@tdc.on.ca</email></para>
</listitem>
<listitem>
<para>Michael Clay <email>mclay@weareb.org</email></para>
</listitem>
<listitem>
<para>Michael Galassi <email>nerd@percival.rain.com</email></para>
</listitem>
<listitem>
<para>Mike Durkin <email>mdurkin@tsoft.sf-bay.org</email></para>
</listitem>
<listitem>
<para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para>
</listitem>
<listitem>
<para>Nate Williams <email>nate@bsd.coe.montana.edu</email></para>
</listitem>
<listitem>
<para>Nick Handel <email>nhandel@NeoSoft.com</email> <email>nick@madhouse.neosoft.com</email></para>
</listitem>
<listitem>
<para>Pace Willisson <email>pace@blitz.com</email></para>
</listitem>
<listitem>
<para>Paul Kranenburg <email>pk@cs.few.eur.nl</email></para>
</listitem>
<listitem>
<para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para>
</listitem>
<listitem>
<para>Paul Popelka <email>paulp@uts.amdahl.com</email></para>
</listitem>
<listitem>
<para>Peter da Silva <email>peter@NeoSoft.com</email></para>
</listitem>
<listitem>
<para>Phil Sutherland <email>philsuth@mycroft.dialix.oz.au</email></para>
</listitem>
<listitem>
<para>Poul-Henning Kamp<email>phk@FreeBSD.ORG</email></para>
</listitem>
<listitem>
<para>Ralf Friedl <email>friedl@informatik.uni-kl.de</email></para>
</listitem>
<listitem>
<para>Rick Macklem <email>root@snowhite.cis.uoguelph.ca</email></para>
</listitem>
<listitem>
<para>Robert D. Thrush <email>rd@phoenix.aii.com</email></para>
</listitem>
<listitem>
<para>Rodney W. Grimes <email>rgrimes@cdrom.com</email></para>
</listitem>
<listitem>
<para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para>
</listitem>
<listitem>
<para>Scott Burris <email>scott@pita.cns.ucla.edu</email></para>
</listitem>
<listitem>
<para>Scott Reynolds <email>scott@clmqt.marquette.mi.us</email></para>
</listitem>
<listitem>
<para>Sean Eric Fagan <email>sef@kithrup.com</email></para>
</listitem>
<listitem>
<para>Simon J Gerraty <email>sjg@melb.bull.oz.au</email> <email>sjg@zen.void.oz.au</email></para>
</listitem>
<listitem>
<para>Stephen McKay <email>syssgm@devetir.qld.gov.au</email></para>
</listitem>
<listitem>
<para>Terry Lambert <email>terry@icarus.weber.edu</email></para>
</listitem>
<listitem>
<para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para>
</listitem>
<listitem>
<para>Tor Egge <email>Tor.Egge@idi.ntnu.no</email></para>
</listitem>
<listitem>
<para>Warren Toomey <email>wkt@csadfa.cs.adfa.oz.au</email></para>
</listitem>
<listitem>
<para>Wiljo Heinen <email>wiljo@freeside.ki.open.de</email></para>
</listitem>
<listitem>
<para>William Jolitz <email>withheld</email></para>
</listitem>
<listitem>
<para>Wolfgang Solfrank <email>ws@tools.de</email></para>
</listitem>
<listitem>
<para>Wolfgang Stanglmeier <email>wolf@dentaro.GUN.de</email></para>
</listitem>
<listitem>
<para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para>
</listitem>
</itemizedlist>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-shorttag: nil
sgml-always-quote-attributes: t
sgml-minimize-attributes: max
sgml-parent-document: ("../handbook.sgml" "part" "chapter")
End:
-->
Reference in a new issue View git blame Copy permalink