diff options
Diffstat (limited to 'en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml')
| -rw-r--r-- | en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml | 5400 |
1 files changed, 0 insertions, 5400 deletions
diff --git a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml deleted file mode 100644 index c04d625c12..0000000000 --- a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml +++ /dev/null @@ -1,5400 +0,0 @@ - - <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>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.dg;</para> - </listitem> - - </itemizedlist> - - </listitem> - - <listitem> - <para>Implement kernel and user vm86 support. Coordinator: - &a.jlemon;</para> - </listitem> - - <listitem> - <para>Implement Int13 vm86 disk driver. Coordinator: - &a.hackers;</para> - </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>Merge the 3c509 and 3c590 drivers (essentially - provide a PCI probe for ep.c).</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.msmith; 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.msmith; 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 "weekend hackers", - 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 — 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) — just send an email to - &a.doc; asking if anyone is working on it. Note that you - are not committing yourself to translating every single - FreeBSD document by doing this — in fact, the documentation - most in need of translation is the installation - instructions.</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. Upload very large submissions to <ulink url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/">ftp.freebsd.org:/pub/FreeBSD/incoming/</ulink>.</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 - “FreeBSD-current” 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 “context diff” - 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 “no strings attached” nature and general - attractiveness to commercial enterprises. Far from - discouraging such commercial use, the FreeBSD Project - actively encourages such participation by commercial - interests who might eventually be inclined to invest - something of their own into FreeBSD.</para> - </listitem> - - <listitem> - <para>The GNU Public License, or “GPL”. This license is not - quite as popular with us due to the amount of extra effort - demanded of anyone using the code for commercial purposes, - but given the sheer quantity of GPL'd code we currently - require (compiler, assembler, text formatter, etc) it would - be silly to refuse additional contributions under this - license. Code under the GPL also goes into a different part - of the tree, that being <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 “BSD-style” copyright on your work, include the - following text at the very beginning of every source code file you - wish to protect, replacing the text between the - <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. - - $Id$</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 “the ports collection”. 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. 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><sys/param.h></filename>. Hopefully that file - is already included; if not, add the code:</para> - - <programlisting> -#if (defined(__unix__) || defined(unix)) && !defined(USG) -#include <sys/param.h> -#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 <sys/param.h> -#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) && (BSD >= 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) && (BSD >= 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__ > 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__ >= 2 -#include <osreldate.h> -# if __FreeBSD_version >= 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 - “2.2.5-STABLE” after the 2.2.5-RELEASE. The pattern used to - be year followed by the month, but we decided to change it - to a more straightforward major/minor system starting from - 2.2. This is because the parallel development on several - branches made it infeasible to classify the releases simply - by their real release dates. If you are making a port now, - you don't have to worry about old -current's; they are - listed here just for your reference.</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 -# -# $Id$ -# - -DISTNAME= oneko-1.1b -CATEGORIES= games -MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ - -MAINTAINER= asami@FreeBSD.ORG - -MAN1= oneko.1 -MANCOMPRESSED= yes -USE_IMAKE= yes - -.include <bsd.port.mk></programlisting> - - <para>See if you can figure it out. Do not worry about the - contents of the <literal>$Id$</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 or an - in-depth description on how to use or compile the port! - <emphasis>Please be careful if you are copying from the - <filename>README</filename> or manpage</emphasis>; too often - they are not a concise description of the port or are in an - awkward format (e.g., manpages have justified spacing). If the - ported software has an official WWW homepage, you should list - it here.</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.) - -http://www.oneko.org/ - -- 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>). If you are using the - <makevar>MAN<replaceable>n</replaceable></makevar> variables (as - you should be), do not list any manpages here.</para> - - <para>Here is a small example:</para> - - <programlisting> -bin/oneko -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>First, make sure you have read the <link - linkend="porting-dads">Do's and Dont's</link> section.</para> - - <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. We do not need your - <filename>work</filename> directory or the - <filename>pkgname.tgz</filename> package, so delete them - now. Next, simply include the output of <command>shar `find - port_dir`</command> in a bug report and send it with the - <citerefentry> - <refentrytitle>send-pr</refentrytitle> - <manvolnum>1</manvolnum> - </citerefentry> program. If the uncompressed port is larger than - 20KB, you should compress it into a tarfile and use <citerefentry> - <refentrytitle>uuencode</refentrytitle> - <manvolnum>1</manvolnum> - </citerefentry> before including it in the bug report (uuencoded - tarfiles are acceptable even if the bug report is smaller than - 20KB but are not preferred). Be sure to classify the bug report as - category <literal>ports</literal> and class - <literal>change-request</literal>.</para> - - <para>One more time, <emphasis>do not include the original source - distfile, the <filename>work</filename> directory, or the - package you built with <command>make - package</command></emphasis>.</para> - - <para>See <link linkend="contrib-general">Bug Reports and General - Commentary</link> for more information.</para> - - <para>We will look at your port, - get back to you if necessary, and put it in the - tree. Your name will also appear in the list of “Additional - FreeBSD contributors” on the FreeBSD Handbook and other files. - Isn't that great?!? <!-- 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>:></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 port's - 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 “main” 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, you might want to put a copy on a - reliable http or ftp server that you control. If you are a FreeBSD - committer, your <filename>public_html</filename> directory on - <hostid>freefall</hostid> is ideal. Make sure you set - <makevar>MASTER_SITE</makevar> to reflect your choice. If you - cannot find somewhere convenient and reliable to put the distfile, - we can “house” 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 “plug-and-play” - 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 — 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 “overnight builds” 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>“build” 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=${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>:></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>${MOTIFLIB} - ${XTOOLLIB} ${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>ELF support</title> - - <para>Since FreeBSD is moving to ELF from 3.0-release onwards, - we need to convert many ports that build shared libraries - to support ELF. Complicating this task is that a 3.0 - system can run as both ELF and a.out, and that there will - be one more release (2.2.8) from the 2.2 branch. Below - are the guidelines on how to convert a.out only ports to - support both a.out and ELF compilation.</para> - - <para>Some part of this list is only applicable during the - conversion, but will be left here for awhile for reference - in case you have come across some old port you wish to - upgrade.</para> - - <sect4> - <title>Moving a.out libraries out of the way</title> - - <para>A.out libraries should be moved out of - <filename>/usr/local/lib</filename> and similar to an - <filename>aout</filename> subdirectory. (If you don't move them - out of the way, ELF ports will happily overwrite a.out libraries.) - The <maketarget>move-aout-libs</maketarget> target in the -current - <filename>src/Makefile</filename> (called from - <maketarget>aout-to-elf</maketarget>) will do this for you. It - will only move a.out libs so it is safe to call it on a system - with both ELF and a.out libs in the standard directories.</para> - </sect4> - - <sect4> - <title>Format</title> - - <para>The ports tree will build packages in the format the machine - is in. This means a.out for 2.2 and a.out or ELF for 3.0 depending - on what <command>`objformat`</command> returns. Also, once users - move a.out libraries to a subdirectory, building a.out libraries - will be unsupported. (I.e., it may still work if you know what you - are doing, but you are on your own.)</para> - - <note> - <para>If a port only works for a.out, set - <makevar>BROKEN_ELF</makevar> to a string describing the reason - why. Such ports will be skipped during a build on an ELF - system.</para> - </note> - </sect4> - - <sect4> - <title><makevar>PORTOBJFORMAT</makevar></title> - - <para><filename>bsd.port.mk</filename> will set - <makevar>PORTOBJFORMAT</makevar> to <literal>aout</literal> or - <literal>elf</literal> and export it in the environments - <envar>CONFIGURE_ENV</envar>, <envar>SCRIPTS_ENV</envar> and - <envar>MAKE_ENV</envar>. (It's always going to be - <literal>aout</literal> in -stable). It is also passed to - <maketarget>PLIST_SUB</maketarget> as - <literal>PORTOBJFORMAT=${PORTOBJFORMAT}</literal>. (See comment - on <literal>ldconfig</literal> lines below.)</para> - - <para>The variable is set using this line in - <filename>bsd.port.mk</filename>:</para> - - <programlisting> -PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout</programlisting> - - <para>Ports' make processes should use this variable to decide what - to do. However, if the port's <filename>configure</filename> - script already automatically detects an ELF system, it is not - necessary to refer to <makevar>PORTOBJFORMAT</makevar>.</para> - </sect4> - - <sect4> - <title>Building shared libraries</title> - - <para>The following are differences in handling shared - libraries for a.out and ELF.</para> - - <itemizedlist> - <listitem> - <para>Shared library versions</para> - - <para>An ELF shared library should be called - <filename>libfoo.so.<replaceable>M</replaceable></filename> - where <replaceable>M</replaceable> is the single version - number, and an a.out library should be called - <filename>libfoo.so.<replaceable>M</replaceable>.<replaceable>N</replaceable></filename> where <replaceable>M</replaceable> is the major version and <replaceable>N</replaceable> is the the minor version number. Do not mix those; <emphasis>never</emphasis> install an ELF shared library called <filename>libfoo.so.<replaceable>N</replaceable>.<replaceable>M</replaceable></filename> or an a.out shared library (or symlink) called <filename>libfoo.so.<replaceable>N</replaceable></filename>.</para> - </listitem> - - <listitem> - <para>Linker command lines</para> - - <para>Assuming <command>cc -shared</command> is used rather than - <command>ld</command> directly, the only difference is that - you need to add - <option>-Wl,-<replaceable>soname,libfoo.so.M</replaceable></option> on the command line for ELF.</para> - </listitem> - </itemizedlist> - - <para>You need to install a symlink from - <filename>libfoo.so</filename> to - <filename>libfoo.so.<replaceable>N</replaceable></filename> to - make ELF linkers happy. Since it should be listed in - <filename>PLIST</filename> too, and it won't hurt in the a.out - case (some ports even require the link for dynamic loading), you - should just make this link regardless of the setting of - <makevar>PORTOBJFORMAT</makevar>.</para> - </sect4> - - <sect4> - <title><makevar>LIB_DEPENDS</makevar></title> - - <para>All port Makefiles are edited to remove minor numbers from - <makevar>LIB_DEPENDS</makevar>, and also to have the regexp - support removed. (E.g., <literal>foo\\.1\\.\\(33|40\\)</literal> - becomes <literal>foo.2</literal>.) They will be matched using - <command>grep -wF</command>.</para> - </sect4> - - <sect4> - <title><filename>PLIST</filename></title> - - <para><filename>PLIST</filename> should contain the short (ELF) - shlib names if the a.out minor number is zero, and the long - (a.out) names otherwise. <filename>bsd.port.mk</filename> will - automatically add <literal>.0</literal> to the end of short shlib - lines if <makevar>PORTOBJFORMAT</makevar> equals - <literal>aout</literal>, and will delete the minor number from - long shlib names if <makevar>PORTOBJFORMAT</makevar> equals - <literal>elf</literal>.</para> - - <para>In cases where you really need to install shlibs with two - versions on an ELF system or those with one version on an a.out - system (for instance, ports that install compatibility libraries - for other operating systems), define the variable - <makevar>NO_FILTER_SHLIBS</makevar>. This will turn off the - editing of <filename>PLIST</filename> mentioned in the previous - paragraph.</para> - </sect4> - - <sect4> - <title><literal>ldconfig</literal></title> - - <para>The <literal>ldconfig/ line in Makefiles should read:</literal></para> - - <programlisting> -${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m ....</programlisting> - - <para>In <filename>PLIST</filename> it should read;</para> - - <programlisting> -@exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... -@unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R</programlisting> - - <para>This is to ensure that the correct <command>ldconfig</command> - will be called depending on the format of the package, not the - default format of the system.</para> - </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>${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 <bsd.port.mk></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>Changing the <filename>PLIST</filename> based on <citerefentry> - <refentrytitle>make</refentrytitle> - <manvolnum>1</manvolnum> - </citerefentry> variables</title> - - <para>Some ports, particularly the <filename>p5-</filename> ports, - need to change their <filename>PLIST</filename> depending on what - options they are configured with (or version of perl, in the case of - <filename>p5-</filename> ports). To make this easy, any instances in - the <filename>PLIST</filename> of <literal>%%OSREL%%</literal>, - <literal>%%PERL_VER%%</literal>, and - <literal>%%PERL_VERSION%%</literal> will be substituted for - appropriately. If you need to make other substitutions, you can set - the <makevar>PLIST_SUB</makevar> variable with a list of - <literal><replaceable>VAR</replaceable>=<replaceable>VALUE</replaceable></literal> pairs and instances of <literal>%%<replaceable>VAR</replaceable>%%</literal> will be substituted with <replaceable>VALUE</replaceable> in the <filename>PLIST</filename>.</para> - </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 “do not sell for profit” 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 “no commercial use” 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 (e.g., if your modified port - 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><anchor id="porting-dads">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.You should check your own port - against this list, but you can also check ports in the PR - database that others have submitted. Submit any comments on - ports you check as described in <link linkend="contrib-general">Bug - Reports and General Commentary</link>. Checking ports in - the PR database will both make it faster for us to commit them, - and prove that you know what you are doing.</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>Portlint Clean</title> - - <para>Do use <command>portlint</command>! The <ulink - url="http://www.freebsd.org/cgi/ports.cgi?portlint">portlint</ulink> program is part of the ports collection.</para> - </sect4> - - <sect4> - <title>Strip Binaries</title> - - <para>Do strip binaries. If the original source already strips the - binaries, fine; otherwise you should add a - <literal>post-install</literal> rule to to it yourself. Here is an - example;</para> - - <programlisting> -post-install: - strip ${PREFIX}/bin/xdl</programlisting> - - <para>Use the <citerefentry> - <refentrytitle>file</refentrytitle> - <manvolnum>1</manvolnum> - </citerefentry> command on the installed executable to check - whether the binary is stripped or not. If it does not say - <literal>not stripped</literal>, it is stripped.</para> - </sect4> - - <sect4> - <title>Correctly Install Manpages</title> - - <para>Do use the <makevar>MAN<replaceable>n</replaceable></makevar> - variables. These variables, will automatically add any manpages - to <filename>pkg/PLIST</filename> (this means you must - <emphasis>not</emphasis> list manpages in the - <filename>PLIST</filename>) and automatically compress manpages - (unless <makevar>NOMANCOMPRESS</makevar> is set in - <filename>/etc/make.conf</filename>). If your port installs - pre-compressed manpages, you must define the - <makevar>MANCOMPRESSED</makevar> variable.</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 <command>Imake</command> 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 <literal>1-9</literal>, - <literal>L</literal> or <literal>N</literal>).</para> - </sect4> - - <sect4> - <title>INSTALL_* 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 - <maketarget>*-install</maketarget> 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 - <command>pkg_add</command>. The first time will as - <command>INSTALL ${PKGNAME} PRE-INSTALL</command> and the second - time as <command>INSTALL ${PKGNAME} POST-INSTALL</command>. - <literal>$2</literal> can be tested to determine which mode - the script is being run in.</para> - - <para>The <envar>PKG_PREFIX</envar> environmental variable will be - set to the package installation directory. See <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> - “requirements” 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>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>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>$</literal>) signs, and typically start with - <literal>$Id</literal> or <literal>$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 resulting 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_X_PREFIX</makevar> or <makevar>USE_IMAKE</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>Do not set <makevar>USE_X_PREFIX</makevar> unless your port - truly require it (i.e., it links against X libs or it needs to - reference files in <makevar>X11BASE</makevar>.</para> - - <para>The variable <makevar>PREFIX</makevar> - can be reassigned in your <filename>Makefile</filename> or in the user's - environment. However, it is strongly discouraged for - individual ports to set this variable explicitly in the - <filename>Makefiles</filename>.</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=\"${PREFIX}/bin/less\"</programlisting> - - or - - <programlisting> --DPAGER=\"${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 “news”. 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 (“Help, xinit does not run anymore after I - install this port!”). 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 to be on the - installed system, let the <filename>pkg/INSTALL</filename> - script call <command>pw</command> to create it - automatically. Look at <filename>net/cvsup-mirror</filename> - for an example.</para> - - <para>If your port must use the same user/group ID number when it is - installed a binarypackage as when it was compiled, then you mus - choose a free UID from 50 to 99 and register it below. Look at - <filename>japanese/Wnn</filename> for an example.</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 include a notice when you submit a port (or an - upgrade) that reserves a new UID or GID in this range. This allows - us to keep the list of reserved IDs up to date.</para> - - </sect4> - - <sect4> - <title>Doing things rationally</title> - - <para>The <filename>Makefile</filename> should do things simply and - reasonably. If you can make it a couple of lines shorter or more - readable, then do so. Examples include using a make - <literal>.if</literal> construct instead of a shell - <literal>if</literal> construct, not redefining - <maketarget>do-extract</maketarget> if you can redefine - <makevar>EXTRACT*</makevar> instead, and using - <makevar>GNU_CONFIGURE</makevar> instead of - <literal>CONFIGURE_ARGS += - --prefix=${PREFIX}</literal>.</para> - </sect4> - - <sect4> - <title>Respect <makevar>CFLAGS</makevar></title> - - <para>The port should respect the <makevar>CFLAGS</makevar> - variable. If it doesn't, please add <literal>NO_PACKAGE=ignores - cflags</literal> to the <filename>Makefile</filename>.</para> - </sect4> - - <sect4> - <title>Miscellanea</title> - - <para>The files <filename>pkg/DESCR</filename>, - <filename>pkg/COMMENT</filename>, and - <filename>pkg/PLIST</filename> should each be double-checked. If - you are reviewing a port and feel they can be worded better, do - so.</para> - - <para>Don't copy more copies of the GNU General Public License into - our system, please.</para> - - <para>Please be careful to note any legal issues! Don't let us - illegally distribute software!</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 <asami@FreeBSD.ORG> -# -# $Id$ -[ ^^^^ This will be automatically replaced with RCS ID string by CVS -when it is committed to our repository.] -# - -[section to describe the port itself and the master site - DISTNAME - is always first, followed by PKGNAME (if necessary), CATEGORIES, - and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR. - After those, one of EXTRACT_SUFX or DISTFILES can be specified too.] -DISTNAME= xdvi -PKGNAME= xdvi-pl18 -CATEGORIES= print -[do not forget the trailing slash ("/")! - if you aren't using MASTER_SITE_* macros] -MASTER_SITES= ${MASTER_SITE_XCONTRIB} -MASTER_SITE_SUBDIR= applications -[set this if the source is not in the standard ".tar.gz" form] -EXTRACT_SUFX= .tar.Z - -[section for distributed patches -- can be empty] -PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ -PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz - -[maintainer; *mandatory*! This is the person (preferably with commit - privileges) who a user can contact for questions and bug reports - this - person should be the porter or someone who can forward questions to the - original porter reasonably promptly. If you really do not want to have - your address here, set it to "ports@FreeBSD.ORG".] -MAINTAINER= asami@FreeBSD.ORG - -[dependencies -- can be empty] -RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript -LIB_DEPENDS= Xpm\\.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 <bsd.port.mk></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 capital letters are - important to the name (for example, with one-letter names - like <literal>R</literal> or <literal>V</literal>) you may use capital letters at your discretion. - There is a tradition of naming Perl 5 modules by prepending - <literal>p5-</literal> and converting the double-colon separator to a hyphen; - for example, the <literal>Data::Dumper</literal> module becomes - <literal>p5-Data-Dumper</literal>. If the software in question has numbers, - hyphens, or underscores in its name, you may include them as - well (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>Changes to this document and the ports system</title> - - <para>If you maintain a lot of ports, you should consider following - the <email>ports@FreeBSD.ORG</email> mailing-list. Important changes to - the way ports work will be announced there. You can always - find more detailed information on the latest changes by - looking at <ulink - url="http://www.FreeBSD.ORG/cgi/cvsweb.cgi/src/share/mk/bsd.port.mk"> - the bsd.port.mk CVS log</ulink>.</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><anchor id="donations">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.dg; with the goal of furthering the aims of the FreeBSD - Project and giving it a minimal corporate presence. Any and all - funds donated (as well as any profits that may eventually be - realized by FreeBSD, Inc.) will be used exclusively to further - the project's goals.</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>(currently using the Walnut Creek CDROM address until a PO -box can be opened)</para> - - <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.dg; 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>Don Scott Wilde</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>Robert T. Morris</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 and OpenBSD that have been integrated into - FreeBSD as well, and we would therefore like to thank all the - contributors to NetBSD and OpenBSD for their work.</para> - - </sect1> - - <sect1 id="contrib-additional"> - <title>Additional FreeBSD Contributors</title> - - <para>(in alphabetical order by first name):</para> - - - <itemizedlist> - <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>Adam McDougall <email>mcdouga9@egr.msu.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>Amancio Hasty <email>ahasty@freebsd.org</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 Gallatin <email>gallatin@cs.duke.edu</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 C. Chavez <email>magus@xmission.com</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 Fumerola <email>billf@jade.chc-chimes.com</email></para> - </listitem> - - <listitem> - <para>Bill Kish <email>kish@osf.org</email></para> - </listitem> - - <listitem> - <para>Brandon Gillespie <email>brandon@roguetrader.com</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>Bruce Mah <email>bmah@ca.sandia.gov</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>Chia-liang Kao <email>clkao@CirX.ORG</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>Christopher T. Johnson - <email>cjohnson@neunacht.netgsi.com</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@ddm.on.ca</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>Dmitry Kohmanyuk <email>dk@farm.org</email></para> - </listitem> - - <listitem> - <para>Dom Mitchell <email>dom@myrddin.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Don Croyle <email>croyle@gelemna.ft-wayne.in.us</email></para> - </listitem> - - <listitem> - <para>&a.whiteside;</para> - </listitem> - - <listitem> - <para>Don Yuniskis <email>dgy@rtd.com</email></para> - </listitem> - - <listitem> - <para>Donald Maddox <email>dmaddox@scsn.net</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>Eckart “Isegrim” Hofmann - <email>Isegrim@Wunder-Nett.org</email></para> - </listitem> - - <listitem> - <para>Eiji-usagi-MATSUmoto <email>usagi@clave.gr.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>Frank Volf <email>volf@oasis.IAEhv.nl</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>Gilad Rom <email>rom_glsa@ein-hashofet.co.uk</email></para> - </listitem> - - <listitem> - <para>Ginga Kawaguti - <email>ginga@amalthea.phys.s.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Greg Ungerer <email>gerg@stallion.oz.au</email></para> - </listitem> - - <listitem> - <para>Hans Huebner <email>hans@artcom.de</email></para> - </listitem> - - <listitem> - <para>Hans Petter Bieker <email>hanspb@persbraten.vgs.no</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>HONDA Yasuhiro <email>honda@kashio.info.mie-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Horance Chou <email>horance@freedom.ie.cycu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Hung-Chi Chu <email>hcchu@r350.ee.ntu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Ian Struble <email>ian@broken.net</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>Iseei Suzuki <email>issei@jp.FreeBSD.ORG</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. Han <email>jtc@cygnus.com</email></para> - </listitem> - - <listitem> - <para>J.T. Conklin <email>jtc@cygnus.com</email></para> - </listitem> - - <listitem> - <para>J.T. Lang <email>keith@email.gcn.net.tw</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>Keff Kletsky <email>Jeff@Wagsky.com</email></para> - </listitem> - - <listitem> - <para>Jeffrey Wheat <email>jeff@cetlink.net</email></para> - </listitem> - - <listitem> - <para>Jerry Hicks <email>jhicks@glenatl.glenayre.com</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>Jimbo Bahooli - <email>griffin@blackhole.iceworld/org</email></para> - </listitem> - - <listitem> - <para>Joao Carlos Mendes Luis <email>jonny@coppe.ufrj.br</email></para> - </listitem> - - <listitem> - <para>Joe “Marcus” Clarke - <email>marcus@miami.edu</email></para> - </listitem> - - <listitem> - <para>Joe Jih-Shian Lu <email>jslu@dns.ntu.edu.tw</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 Hood <email>cgull@owl.org</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>John Saunders <email>john@pacer.nlc.net.au</email></para> - </listitem> - - <listitem> - <para>Jonathan Hanna - <email>jh@pc-21490.bc.rogers.wave.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>Junya WATANABE <email>junya-w@remus.dti.ne.jp</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>Kentaro Inagaki <email>JBD01226@niftyserve.ne.jp</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 Köller <email>Lars.Koeller@Uni-Bielefeld.DE</email></para> - </listitem> - - <listitem> - <para>Lian Tai-hwa - <email>avatar@www.mmlab.cse.yzu.edu.twu</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>Makoto WATANABE - <email>watanabe@zlab.phys.nagoya-u.ac.jp</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>Masanori Kiriake <email>seiken@ncs.co.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 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>Motoyuki Kasahara <email>m-hasahr@sra.co.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 Breuninger <email>ob@seicom.NET</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 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. M. Neswold <email>rneswold@drmemory.fnal.gov</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>SADA Kenji <email>sada@e-mail.ne.jp</email></para> - </listitem> - - <listitem> - <para>SURANYI Peter <email>suranyip@jks.is.tsukuba.ac.jp</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>Scot W. Hetzel <email>hetzels@westbend.net</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>Seigou TANIMURA - <email>tanimura@naklab.dnj.ynu.ac.jp</email></para> - </listitem> - - <listitem> - <para>Seiichirou Hiraoka <email>flathill@flathill.gr.jp</email></para> - </listitem> - - <listitem> - <para>Serge Babkin <email>babkin@hq.icb.chel.su</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>Shigeyuki FUKUSHIMA - <email>shige@kuis.kyoto-u.ac.jp</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 Eggers <email>seggers@semyam.dinoco.de</email></para> - </listitem> - - <listitem> - <para>Stefan Moeding <email>s.moeding@ndh.net</email></para> - </listitem> - - <listitem> - <para>Stefan “Sec” Zehl <email>sec@42.org</email></para> - </listitem> - - <listitem> - <para>Stephane Legrand <email>stephane@lituus.fr</email></para> - </listitem> - - <listitem> - <para>Stephen Farrell <email>stephen@farrell.org</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>Steven G. Kargl - <email>kargl@troutmask.apl.washington.edu</email></para> - </listitem> - - <listitem> - <para>Stephen H. Samorodin <email>samorodi@NUXU.com</email></para> - </listitem> - - <listitem> - <para>Stuart Henderson - <email>stuart@internationalschool.co.uk</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>Takashi Mega <email>mega@minz.org</email></para> - </listitem> - - <listitem> - <para>Takashi Uozu <email>j1594016@ed.kagu.sut.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takayuki Ariga <email>a00821@cc.hc.keio.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takeu NAIKI <email>naiki@bfd.es.hokudai.ac.jp</email></para> - </listitem> - - <listitem> - <para>Ted Faber <email>faber@ISI.EDU</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önig <email>Thomas.Koenig@ciw.uni-karlsruhe.de</email></para> - </listitem> - - <listitem> - <para>Þórður Í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 Jobbins <email>tom@tom.tj</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>Toshihiko SHIMOKAWA <email>toshi@tea.forus.or.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>Vladimir Kushnir <email>kushn@mail.kar.net</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@technologist.com</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>dg@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örg Lohse <email>lohse@tech7.informatik.uni-hamburg.de</email></para> - </listitem> - - <listitem> - <para>Jö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: ---> - |