From owner-p4-projects@FreeBSD.ORG Tue Apr 10 12:28:26 2012 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 2E84910656EB; Tue, 10 Apr 2012 12:28:26 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E461F10656D1 for ; Tue, 10 Apr 2012 12:28:25 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from skunkworks.freebsd.org (skunkworks.freebsd.org [IPv6:2001:4f8:fff6::2d]) by mx1.freebsd.org (Postfix) with ESMTP id CB7A38FC12 for ; Tue, 10 Apr 2012 12:28:25 +0000 (UTC) Received: from skunkworks.freebsd.org (localhost [127.0.0.1]) by skunkworks.freebsd.org (8.14.4/8.14.4) with ESMTP id q3ACSPtu047107 for ; Tue, 10 Apr 2012 12:28:25 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by skunkworks.freebsd.org (8.14.4/8.14.4/Submit) id q3ACSPAl047102 for perforce@freebsd.org; Tue, 10 Apr 2012 12:28:25 GMT (envelope-from rene@FreeBSD.org) Date: Tue, 10 Apr 2012 12:28:25 GMT Message-Id: <201204101228.q3ACSPAl047102@skunkworks.freebsd.org> X-Authentication-Warning: skunkworks.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Precedence: bulk Cc: Subject: PERFORCE change 209355 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:28:26 -0000 http://p4web.freebsd.org/@@209355?ac=10 Change 209355 by rene@rene_acer on 2012/04/10 12:27:29 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#53 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#134 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/arch-handbook/pccard/chapter.sgml#3 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/developers-handbook/introduction/chapter.sgml#3 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.sgml#14 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml#36 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#22 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#135 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/config/chapter.sgml#40 integrate .. //depot/projects/docproj_nl/share/sgml/man-refs.ent#42 integrate .. //depot/projects/docproj_nl/www/en/releases/8.3R/relnotes-detailed.html#2 integrate .. //depot/projects/docproj_nl/www/en/releases/8.3R/schedule.sgml#5 integrate .. //depot/projects/docproj_nl/www/share/sgml/news.xml#137 integrate .. //depot/projects/docproj_nl/www/share/sgml/release.ent#45 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#53 (text+ko) ==== @@ -9,7 +9,7 @@ The &os; Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.316 2012/03/24 18:21:49 eadler Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.317 2012/04/03 12:07:47 gavin Exp $ 1999 @@ -77,7 +77,7 @@ Main Subversion Root - svn+ssh://svn.FreeBSD.org/base (see also ). + svn+ssh://svn.FreeBSD.org/base (see also ). @@ -255,7 +255,8 @@ It is assumed that you are already familiar with the basic operation of the version control systems in use. Traditionally this was - CVS, but as of June 2008, Subversion is used for the src tree. + CVS, but as of June 2008, Subversion is used for the src tree. + Subversion is covered in . The &a.cvsadm; are the owners of the repository and are responsible for direct modification of it for the purposes of ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml#134 (text+ko) ==== @@ -1,4 +1,4 @@ - + @@ -12,22 +12,24 @@ This chapter will talk about the FreeBSD mechanisms for writing a device driver for a PC Card or CardBus device. However, - at the present time, it just documents how to add a driver to an + at present it just documents how to add a new device to an existing pccard driver. - Adding a device + Adding a Device - Devices drivers know what devices they - support. There is a table of supported devices in the - kernel that drivers use to attach to a device. + Device drivers know what devices they support. There is a + table of supported devices in the kernel that drivers use to + attach to a device. Overview CIS PC Cards are identified in one of two ways, both based on - information in the CIS of the card. The + the Card Information Structure + (CIS) + stored on the card. The first method is to use numeric manufacturer and product numbers. The second method is to use the human readable strings that are also contained in the CIS. The PC Card bus @@ -35,34 +37,33 @@ design pattern to help the driver writer match devices to his driver. - OEMs manufacturers often develop a reference design for - a PC Card product sell this design to other companies to - market. Those companies refine - the design, market the product to their target audience or - geographic area and put their own name plate onto the card. - The refinements to the physical card typically are - very minor, if any changes are made at all. However, - to strengthen their brand, - these vendors place their company name in the human - strings in the CIS space, but leave the manufacturer and - product ids unchanged. + Original equipment manufacturers (OEMs) + often develop a reference design for a PC Card product, then + sell this design to other companies to market. Those + companies refine the design, market the product to their + target audience or geographic area, and put their own name + plate onto the card. The refinements to the physical card are + typically very minor, if any changes are made at all. To + strengthen their brand, these vendors place their company name + in the human readable strings in the CIS space, but leave the + manufacturer and product IDs unchanged. NetGear Linksys D-Link - Because of this practice, FreeBSD drivers tend to - use the numeric IDs. Using numeric IDs and a centralized - database complicates adding IDs and support for cards to the - system. One must carefully check to see who really made the - card, especially when it appears that the vendor who made the - card from might already have a different manufacturer id - listed in the central database. Linksys, D-Link and NetGear - are a number of US Manufacturers of LAN hardware that often - sell the same design. These same designs can be sold in Japan - under names such as Buffalo and Corega. Yet often, these - devices will all have the same manufacturer and product - id. + Because of this practice, FreeBSD drivers usually rely on + numeric IDs for device identification. Using numeric IDs and + a centralized database complicates adding IDs and support for + cards to the system. One must carefully check to see who + really made the card, especially when it appears that the + vendor who made the card might already have a different + manufacturer ID listed in the central database. Linksys, + D-Link, and NetGear are a number of US manufacturers of LAN + hardware that often sell the same design. These same designs + can be sold in Japan under names such as Buffalo and Corega. + Often, these devices will all have the same manufacturer and + product IDs. The PC Card bus code keeps a central database of card information, but not which driver is associated with them, in @@ -72,11 +73,11 @@ devices. Finally, some really low end devices do not contain - manufacturer identification at all. These devices require - that one matches them using the human readable CIS strings. + manufacturer identification at all. These devices must be + detected by matching the human readable CIS strings. While it would be nice if we did not need this method as a fallback, it is necessary for some very low end CD-ROM players - and ethernet cards. This method should generally be + and Ethernet cards. This method should generally be avoided, but a number of devices are listed in this section because they were added prior to the recognition of the OEM nature of the PC Card business. When @@ -86,64 +87,67 @@ Format of <filename>pccarddevs</filename> - There are four sections of the + There are four sections in the pccarddevs files. The first section - lists the manufacturer numbers for those vendors that use + lists the manufacturer numbers for vendors that use them. This section is sorted in numerical order. The next section has all of the products that are used by these vendors, along with their product ID numbers and a description string. The description string typically is not used (instead we set the device's description based on the human readable CIS, even if we match on the numeric version). These two - sections are then repeated for those devices that use the - string matching method. Finally, C-style comments are allowed - anywhere in the file. + sections are then repeated for devices that use the + string matching method. Finally, C-style comments enclosed in + /* and */ characters are + allowed anywhere in the file. The first section of the file contains the vendor IDs. Please keep this list sorted in numeric order. Also, please coordinate changes to this file because we share it with NetBSD to help facilitate a common clearing house for this - information. For example: + information. For example, here are the first few vendor + IDs: -vendor FUJITSU 0x0004 Fujitsu Corporation + vendor FUJITSU 0x0004 Fujitsu Corporation vendor NETGEAR_2 0x000b Netgear vendor PANASONIC 0x0032 Matsushita Electric Industrial Co. vendor SANDISK 0x0045 Sandisk Corporation - shows the first few vendor ids. Chances are very good + Chances are very good that the NETGEAR_2 entry is really an OEM that NETGEAR purchased cards from and the author of support for those cards was unaware at the time that Netgear was using - someone else's id. These entries are fairly straightforward. - There is the vendor keyword used to denote the kind of line - that this is. There is the name of the vendor. This name - will be repeated later in the pccarddevs file, as well as used - in the driver's match tables, so keep it short and a valid C - identifier. There is a numeric ID, in hex, for the + someone else's ID. These entries are fairly straightforward. + The vendor keyword denotes the kind of line that this is, + followed by the name of the vendor. This name will be + repeated later in pccarddevs, as + well as used in the driver's match tables, so keep it short + and a valid C identifier. A numeric ID in hex identifies the manufacturer. Do not add IDs of the form 0xffffffff or 0xffff - because these are reserved ids (the former is 'no id set' - while the latter is sometimes seen in extremely poor quality - cards to try to indicate 'none). Finally there is a string - description of the company that makes the card. This string - is not used in FreeBSD for anything but commentary - purposes. + because these are reserved IDs (the former is + no ID set while the latter is sometimes seen in + extremely poor quality cards to try to indicate + none). Finally there is a string description + of the company that makes the card. This string is not used + in FreeBSD for anything but commentary purposes. The second section of the file contains the products. As - you can see in the following example: + shown in this example, the format is similar to the vendor + lines: -/* Allied Telesis K.K. */ + /* Allied Telesis K.K. */ product ALLIEDTELESIS LA_PCM 0x0002 Allied Telesis LA-PCM /* Archos */ product ARCHOS ARC_ATAPI 0x0043 MiniCD - the format is similar to the vendor lines. There is the - product keyword. Then there is the vendor name, repeated from - above. This is followed by the product name, which is used by - the driver and should be a valid C identifier, but may also - start with a number. There is then the product id for this - card, in hex. As with the vendors, there is the same + The + product keyword is followed by the vendor + name, repeated from above. This is followed by the product + name, which is used by the driver and should be a valid C + identifier, but may also start with a number. As with the + vendors, the hex product ID for this card follows the same convention for 0xffffffff and 0xffff. Finally, there is a string description of the device itself. This string typically is @@ -151,39 +155,39 @@ construct a string from the human readable CIS entries, but it can be used in the rare cases where this is somehow insufficient. The products are in alphabetical order by - manufacturer, then numerical order by product id. They have a + manufacturer, then numerical order by product ID. They have a C comment before each manufacturer's entries and there is a blank line between entries. The third section is like the previous vendor section, but - with all of the manufacturer numeric ids as - -1. -1 means - match anything you find in the FreeBSD pccard + with all of the manufacturer numeric IDs set to + -1, meaning + match anything found in the FreeBSD pccard bus code. Since these are C identifiers, their names must be unique. Otherwise the format is identical to the first section of the file. The final section contains the entries for those cards - that we must match with string entries. This sections' format - is a little different than the generic section: + that must be identified by string entries. This section's + format is a little different from the generic section: -product ADDTRON AWP100 { "Addtron", "AWP-100&spWireless&spPCMCIA", "Version&sp01.02", NULL } + product ADDTRON AWP100 { "Addtron", "AWP-100&spWireless&spPCMCIA", "Version&sp01.02", NULL } product ALLIEDTELESIS WR211PCM { "Allied&spTelesis&spK.K.", "WR211PCM", NULL, NULL } Allied Telesis WR211PCM - We have the familiar product keyword, followed by the - vendor name followed by the card name, just as in the second - section of the file. However, then we deviate from that - format. There is a {} grouping, followed by a number of - strings. These strings correspond to the vendor, product and - extra information that is defined in a CIS_INFO tuple. These - strings are filtered by the program that generates - pccarddevs.h to replace &sp with a - real space. NULL strings mean that the corresponding part - of the entry should be ignored. In the example I have picked, - there is a bad entry. It should not contain the version - number in it unless that is critical for the operation of the - card. Sometimes vendors will have many different versions of - the card in the field that all work, in which case that + The familiar product keyword is + followed by the vendor name and the card name, just as in the + second section of the file. Here the format deviates from + that used earlier. There is a {} grouping, followed by a + number of strings. These strings correspond to the vendor, + product, and extra information that is defined in a CIS_INFO + tuple. These strings are filtered by the program that + generates pccarddevs.h to replace &sp + with a real space. NULL strings mean that the corresponding + part of the entry should be ignored. The example shown here + contains a bad entry. It should not contain the version + number unless that is critical for the operation of the card. + Sometimes vendors will have many different versions of the + card in the field that all work, in which case that information only makes it harder for someone with a similar card to use it with FreeBSD. Sometimes it is necessary when a vendor wishes to sell many different parts under the same @@ -195,7 +199,7 @@ - Sample probe routine + Sample Probe Routine PC Card @@ -241,9 +245,10 @@ first entry that it matches. Some drivers may use this mechanism to convey additional information about some cards to the rest of the driver, so there may be some variance in the - table. The only requirement is that if you have a different - table, the first element of the structure you have a table of - be a struct pccard_product. + table. The only requirement is that each row of the table + must have a struct + pccard_product as the first + element. Looking at the table wi_pccard_products, one notices that @@ -251,41 +256,41 @@ PCMCIA_CARD(foo, bar, baz). The - foo part is the manufacturer id + foo part is the manufacturer ID from pccarddevs. The - bar part is the product. The + bar part is the product ID. baz is the expected function number - that for this card. Many pccards can have multiple functions, + for this card. Many pccards can have multiple functions, and some way to disambiguate function 1 from function 0 is needed. You may see PCMCIA_CARD_D, which - includes the device description from the - pccarddevs file. You may also see + includes the device description from + pccarddevs. You may also see PCMCIA_CARD2 and PCMCIA_CARD2_D which are used when you need - to match CIS both CIS strings and manufacturer numbers, in the + to match both CIS strings and manufacturer numbers, in the use the default description and take the description from pccarddevs flavors. - Putting it all together + Putting it All Together - So, to add a new device, one must do the following steps. - First, one must obtain the identification information from the + To add a new device, one must first obtain the + identification information from the device. The easiest way to do this is to insert the device into a PC Card or CF slot and issue - devinfo -v. You will likely see something - like: + devinfo -v. Sample output: cbb1 pnpinfo vendor=0x104c device=0xac51 subvendor=0x1265 subdevice=0x0300 class=0x060700 at slot=10 function=1 cardbus1 pccard1 unknown pnpinfo manufacturer=0x026f product=0x030c cisvendor="BUFFALO" cisproduct="WLI2-CF-S11" function_type=6 at function=0 - as part of the output. The manufacturer and product are - the numeric IDs for this product. While the cisvendor and - cisproduct are the strings that are present in the CIS that - describe this product. + manufacturer + and product are the numeric IDs for this + product, while cisvendor and + cisproduct are the product description + strings from the CIS. Since we first want to prefer the numeric option, first try to construct an entry based on that. The above card has @@ -295,8 +300,8 @@ vendor BUFFALO 0x026f BUFFALO (Melco Corporation) - so we are good there. Looking for an entry for this card, - we do not find one. Instead we find: + But there is no entry for this particular card. + Instead we find: /* BUFFALO */ product BUFFALO WLI_PCM_S11 0x0305 BUFFALO AirStation 11Mbps WLAN @@ -304,22 +309,23 @@ product BUFFALO LPC3_CLT 0x030a BUFFALO LPC3-CLT Ethernet Adapter product BUFFALO WLI_CF_S11G 0x030b BUFFALO AirStation 11Mbps CF WLAN - we can just add + To add the device, we can just add this entry to + pccarddevs: product BUFFALO WLI2_CF_S11G 0x030c BUFFALO AirStation ultra 802.11b CF - to pccarddevs. Presently, there is a - manual step to regenerate the - pccarddevs.h file used to convey these - identifiers to the client driver. The following steps - must be done before you can use them in the driver: + At present, there is a + manual step to regenerate + pccarddevs.h, used to convey these + identifiers to the client driver. The following steps must be + done before you can use them in the driver: &prompt.root; cd src/sys/dev/pccard -&prompt.root; make -f Makefile.pccarddevs - +&prompt.root; make -f Makefile.pccarddevs - Once these steps are complete, you can add the card to the - driver. That is a simple operation of adding one line: + Once these steps are complete, the card can be added to + the driver. That is a simple operation of adding one + line: static const struct pccard_product wi_pccard_products[] = { PCMCIA_CARD(3COM, 3CRWE737A, 0), @@ -334,39 +340,37 @@ line before the line that I added, but that is simply to highlight the line. Do not add it to the actual driver. Once you have added the line, you can recompile your kernel or - module and try to see if it recognizes the device. If it does - and works, please submit a patch. If it does not work, please - figure out what is needed to make it work and submit a patch. - If it did not recognize it at all, you have done something - wrong and should recheck each step. + module and test it. If the device is recognized and works, + please submit a patch. If it does not work, please figure out + what is needed to make it work and submit a patch. If the + device is not recognized at all, you have done something wrong + and should recheck each step. If you are a FreeBSD src committer, and everything appears to be working, then you can commit the changes to the tree. - However, there are some minor tricky things that you need to - worry about. First, you must commit the - pccarddevs file to the tree. After you - have done that, you must regenerate - pccarddevs.h and commit it as a second - commit (this is to make sure that the right - $FreeBSD$ tag is in the latter file). Finally, - you need to commit the additions to the driver. + However, there are some minor tricky things to be considered. + pccarddevs must be committed to the tree + first. Then pccarddevs.h must be + regenerated and committed as a second step, ensuring that the + right $FreeBSD$ tag is in the latter file. + Finally, commit the additions to the driver. - Submitting a new device + Submitting a New Device - Many people send entries for new devices to the author - directly. Please do not do this. Please submit them as a PR - and send the author the PR number for his records. This makes - sure that entries are not lost. When submitting a PR, it is - unnecessary to include the pccardevs.h - diffs in the patch, since those will be regenerated. It is - necessary to include a description of the device, as well as - the patches to the client driver. If you do not know the - name, use OEM99 as the name, and the author will adjust OEM99 - accordingly after investigation. Committers should not commit - OEM99, but instead find the highest OEM entry and commit one - more than that. + Please do not send entries for new devices to the author + directly. Instead, submit them as a PR and send the author + the PR number for his records. This ensures that entries are + not lost. When submitting a PR, it is unnecessary to include + the pccardevs.h diffs in the patch, since + those will be regenerated. It is necessary to include a + description of the device, as well as the patches to the + client driver. If you do not know the name, use OEM99 as the + name, and the author will adjust OEM99 accordingly after + investigation. Committers should not commit OEM99, but + instead find the highest OEM entry and commit one more than + that. ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/developers-handbook/introduction/chapter.sgml#3 (text+ko) ==== @@ -1,20 +1,20 @@ - Murray - Stokely - Contributed by + Murray + Stokely + Contributed by - Jeroen - Ruigrok van der Werven + Jeroen + Ruigrok van der Werven @@ -33,7 +33,6 @@ profession. The information in this chapter might be aimed toward the beginning programmer; indeed, it could serve useful for the programmer unfamiliar with the &os; platform. - @@ -44,188 +43,214 @@ ideology as well as usability, performance and stability. - + Architectural Guidelines Our ideology can be described by the following - guidelines + guidelines - Do not add new functionality unless an - implementor cannot complete a real application without - it. + + Do not add new functionality unless an implementor + cannot complete a real application without it. + - It is as important to decide what a system is - not as to decide what it is. Do not serve all the world's - needs; rather, make the system extensible so that additional - needs can be met in an upwardly compatible - fashion. + + It is as important to decide what a system is + not as to decide what it is. Do not serve all the world's + needs; rather, make the system extensible so that additional + needs can be met in an upwardly compatible + fashion. + - The only thing worse than generalizing from one - example is generalizing from no examples at - all. + + The only thing worse than generalizing from one example + is generalizing from no examples at all. + - If a problem is not completely understood, it is - probably best to provide no solution at all. + + If a problem is not completely understood, it is + probably best to provide no solution at all. + - If you can get 90 percent of the desired effect - for 10 percent of the work, use the simpler - solution. + + If you can get 90 percent of the desired effect for 10 + percent of the work, use the simpler solution. + - Isolate complexity as much as - possible. + + Isolate complexity as much as possible. + - Provide mechanism, rather than policy. In - particular, place user interface policy in the client's - hands. + + Provide mechanism, rather than policy. In particular, + place user interface policy in the client's hands. + + - - - From Scheifler & Gettys: "X Window System" - + From Scheifler & Gettys: "X Window System" - The Layout of + <title>The Layout of <filename class="directory">/usr/src</filename> The complete source code to FreeBSD is available from our public repository. The source code is normally installed in - /usr/src which contains the - following subdirectories: + /usr/src which contains + the following subdirectories: - + Directory Description - + - bin/ - Source for files in - /bin + bin/ + Source for files in + /bin - + - cddl/ + cddl/ Utilities covered by the Common Development and Distribution License - contrib/ - Source for files from contributed software. + contrib/ + Source for files from contributed + software. - crypto/ - Cryptographical sources + crypto/ + Cryptographical sources - etc/ - Source for files in /etc + etc/ + Source for files in /etc - games/ - Source for files in /usr/games + games/ + Source for files in /usr/games - gnu/ - Utilities covered by the GNU Public License + gnu/ + Utilities covered by the GNU Public + License - include/ - Source for files in /usr/include + include/ + Source for files in /usr/include - kerberos5/ - Source for Kerberos version 5 + kerberos5/ + Source for Kerberos version 5 - lib/ - Source for files in /usr/lib + lib/ + Source for files in /usr/lib - + - libexec/ - Source for files in /usr/libexec + libexec/ + Source for files in /usr/libexec - release/ - Files required to produce a FreeBSD release + release/ + Files required to produce a FreeBSD + release - rescue/ - Build system for the - /rescue utilities + rescue/ + Build system for the + /rescue + utilities - sbin/ - Source for files in /sbin + sbin/ + Source for files in /sbin - secure/ - FreeSec sources + secure/ + FreeSec sources - share/ - Source for files in /usr/share + share/ + Source for files in /usr/share - sys/ - Kernel source files + sys/ + Kernel source files - tools/ - Tools used for maintenance and testing of - FreeBSD + tools/ + Tools used for maintenance and testing of + FreeBSD - usr.bin/ - Source for files in /usr/bin - + usr.bin/ + Source for files in /usr/bin + - usr.sbin/ - Source for files in /usr/sbin - - + usr.sbin/ + Source for files in /usr/sbin + + - - + ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.sgml#14 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -2631,9 +2631,8 @@ troubleshooting The following section covers basic installation - troubleshooting, such as common problems people have reported. - There are also a few questions and answers for people wishing to - dual-boot &os; with &ms-dos; or &windows;. + troubleshooting, such as common problems people have + reported. What to Do If Something Goes Wrong ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml#36 (text+ko) ==== @@ -1,6 +1,6 @@ @@ -598,17 +598,18 @@ KOffice, make sure you have an up-to-date version of KDE. - To install KOffice as a + To install KOffice for + KDE4 as a package, issue the following command: - &prompt.root; pkg_add -r koffice + &prompt.root; pkg_add -r koffice-kde4 If the package is not available, you can use the Ports Collection. For instance, to install KOffice for - KDE3, do: + KDE4, do: - &prompt.root; cd /usr/ports/editors/koffice-kde3 + &prompt.root; cd /usr/ports/editors/koffice-kde4 &prompt.root; make install clean @@ -1263,8 +1264,8 @@ KOffice - koffice - editors/koffice-kde3 + koffice-kde4 + editors/koffice-kde4 ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#22 (text+ko) ==== @@ -1,7 +1,7 @@ @@ -672,7 +672,7 @@ in the 10.X-CURRENT (trunk) branch, and SNAPshot releases of 10.X on CD-ROM (and, of course, on the net) are continually made available from the snapshot + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/">the snapshot server as work progresses. ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/porters-handbook/book.sgml#135 (text+ko) ==== @@ -1,7 +1,7 @@ >>> TRUNCATED FOR MAIL (1000 lines) <<<