MFde: Update the German Documentation set.
Resync many parts of the documentation with the latest revision. Obtained from: The FreeBSD German Documentation Project
This commit is contained in:
Benedict Reuschling
parent
f7e5f56a41
commit
4290ba6ffc
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=37115
6 changed files with 527 additions and 135 deletions
de_DE.ISO8859-1/books
developers-handbook/policies
faq
handbook
|
|
@ -3,8 +3,8 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/policies/chapter.sgml,v 1.10 2010/12/18 13:28:29 jkois Exp $
|
||||
basiert auf: 1.34
|
||||
$FreeBSDde: de-docproj/books/developers-handbook/policies/chapter.sgml,v 1.13 2011/03/27 15:21:02 bcr Exp $
|
||||
basiert auf: 1.37
|
||||
-->
|
||||
|
||||
<chapter id="policies">
|
||||
|
|
@ -15,6 +15,10 @@
|
|||
<surname>Kamp</surname>
|
||||
<contrib>Beigesteuert von </contrib>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Giorgos</firstname>
|
||||
<surname>Keramidas</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<!-- June 1996 -->
|
||||
<authorgroup>
|
||||
|
|
@ -36,40 +40,61 @@
|
|||
<title><makevar>MAINTAINER</makevar> eines Makefiles</title>
|
||||
<indexterm><primary>Ports-Maintainer</primary></indexterm>
|
||||
|
||||
<para>Wenn ein bestimmter Bereich der FreeBSD-Distribution von
|
||||
einer Person oder Gruppe gepflegt wird, kann dies durch
|
||||
Hinzufügen der Zeile
|
||||
<para>Wenn ein bestimmter Bereich der &os;
|
||||
<filename>src/</filename>-Distribution von einer Person oder Gruppe
|
||||
gepflegt wird, kann dies durch einen Eintrag in die Datei
|
||||
<filename>src/MAINTAINERS</filename> der Öffentlichkeit
|
||||
mitgeteilt werden. Maintainer eines Ports in der Ports-Sammlung
|
||||
können ihre Verantwortung über den Port durch einen Eintrag in
|
||||
die <makevar>MAINTAINER</makevar>-Zeile im <filename>Makefile</filename>
|
||||
des Ports der Welt mitteilen.</para>
|
||||
|
||||
<programlisting><makevar>MAINTAINER</makevar>= <replaceable>email-addresses</replaceable></programlisting>
|
||||
|
||||
<programlisting>MAINTAINER= email-addresses</programlisting>
|
||||
<tip>
|
||||
<para>Für andere Teile des Repositories oder andere Abschnitte, die
|
||||
noch keinen Maintainer aufweisen, oder falls Sie sich nicht sicher
|
||||
sind, wer der Maintainer ist, sehen Sie sich die Commit-Historie des
|
||||
betreffenden Ports an. Es ist recht häufig der Fall, dass ein
|
||||
Maintainer nicht explizit aufgeführt ist, aber trotzdem diejenigen
|
||||
Personen, die den Port seit den letzten paar Jahren aktiv betreuen,
|
||||
daran interessiert sind, Änderungen zu begutachten. Selbst wenn
|
||||
dies nicht explizit in der Dokumentation oder im Quellcode erwähnt
|
||||
ist, wird es trotzdem als höfliche Geste angesehen, wenn man
|
||||
nach einer Überprüfung der eigenen Änderungen
|
||||
fragt.</para>
|
||||
</tip>
|
||||
|
||||
im <filename>Makefile</filename> der Öffentlichkeit
|
||||
mitgeteilt werden.</para>
|
||||
<para>Die Rolle eines Maintainers ist die folgende:</para>
|
||||
|
||||
<para>Dies bedeutet folgendes:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Der Maintainer ist verantwortlich für diesen Code. Er
|
||||
oder sie muss einerseits für die Behebung von Fehlern und das
|
||||
Beantworten von Problemberichten für diesen Code die
|
||||
Verantwortung tragen und andererseits, falls es sich um beigesteuerte
|
||||
Software handelt, neue Versionen verfolgen und bereitstellen.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Der Maintainer ist verantwortlich für diesen Code.
|
||||
Er muss einerseits für die Behebung von
|
||||
Fehlern und das Beantworten von Problemberichten für diesen
|
||||
Code die Verantwortung tragen und andererseits, falls es sich
|
||||
um beigesteuerte Software handelt, neue Versionen verfolgen
|
||||
und bereitstellen.</para>
|
||||
<listitem>
|
||||
<para>Änderungen an Verzeichnissen, die ein Maintainer definiert
|
||||
hat, sollten an den Maintainer für eine Überprüfung
|
||||
gesendet werden, bevor diese committet werden. Nur wenn der
|
||||
Maintainer in einer inakzeptablen Zeitspanne auf mehrere E-Mails
|
||||
nicht antwortet, können die Änderungen, die mit dem Commit
|
||||
in Kraft treten, auch ohne Überprüfung durch den Maintainer
|
||||
vollzogen werden. Dennoch wird empfohlen, dass die Änderungen,
|
||||
falls möglich, von jemand anderem überprüft
|
||||
werden.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Änderungen an Verzeichnissen, die ein Maintainer
|
||||
definiert hat, sollten an den Maintainer für eine
|
||||
Überprüfung gesendet werden, bevor diese committet
|
||||
werden. Nur wenn der Maintainer in einer inakzeptablen
|
||||
Zeitspanne auf mehrere E-Mails nicht antwortet, können die
|
||||
Änderungen, die mit dem Commit in Kraft treten, auch ohne
|
||||
Überprüfung durch den Maintainer vollzogen werden.
|
||||
Dennoch wird empfohlen, dass die Änderungen, falls
|
||||
möglich, von jemand anderem überprüft
|
||||
werden.</para>
|
||||
|
||||
<para>Es ist natürlich nicht akzeptabel, einer Person oder
|
||||
Gruppe den Status eines Maintainers zu geben, so lange sie nicht
|
||||
zustimmt, diese Pflicht auf sich zu nehmen. Andererseits muss es
|
||||
kein einzelner Mensch sein. Eine Gruppe von Menschen ist genauso
|
||||
in Ordnung.</para>
|
||||
<listitem>
|
||||
<para>Es ist natürlich nicht akzeptabel, einer Person oder Gruppe
|
||||
den Status eines Maintainers zu geben, so lange sie nicht zustimmt,
|
||||
diese Pflicht auf sich zu nehmen. Andererseits muss es kein einzelner
|
||||
Mensch sein. Eine Gruppe von Menschen ist genauso in Ordnung.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-contributed">
|
||||
|
|
@ -84,6 +109,10 @@
|
|||
<firstname>David</firstname>
|
||||
<surname>O'Brien</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Gavin</firstname>
|
||||
<surname>Atkinson</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<!-- June 1996 -->
|
||||
</sect1info>
|
||||
|
|
@ -114,9 +143,9 @@
|
|||
alten Methode gibt. Dazu gehört auch, dass jeder
|
||||
einfach Diffs bezüglich der
|
||||
<quote>offiziellen</quote> Quelltext-Versionen erzeugen kann
|
||||
(auch ohne CVS-Zugang). Dies wird es deutlich vereinfachen,
|
||||
Änderungen an die Hauptentwickler zurückfließen zu
|
||||
lassen.</para>
|
||||
(auch ohne direkten Repository-Zugang). Dies wird es deutlich
|
||||
vereinfachen, Änderungen an die Hauptentwickler
|
||||
zurückfließen zu lassen.</para>
|
||||
|
||||
<para>Letztendlich kommt es jedoch auf die Menschen an, welche die
|
||||
Arbeit leisten. Wenn die Durchführung dieses Modells bei
|
||||
|
|
@ -128,71 +157,61 @@
|
|||
Entscheidung.</para>
|
||||
|
||||
<note>
|
||||
<para>Durch einige bedauernswerte Einschränkungen
|
||||
des RCS-Dateiformats und die Handhabung von Herstellerzweigen
|
||||
im CVS ist von unwesentlichen, trivialen und/oder kosmetischen
|
||||
Änderungen an Dateien <emphasis>dringend
|
||||
<para>Durch einige bedauernswerte Einschränkungen des <acronym
|
||||
role="Revision Control System">RCS</acronym>-Dateiformats und die
|
||||
Handhabung von Herstellerzweigen ist von unwesentlichen, trivialen
|
||||
und/oder kosmetischen Änderungen an Dateien <emphasis>dringend
|
||||
abzuraten</emphasis>, die dem Herstellerzweig folgen.
|
||||
<quote>Grammatikalische oder sprachliche
|
||||
Fehlerbehebungen</quote> sind explizit unter der
|
||||
<quote>Kosmetik</quote>-Kategorie einzuordnen und sollten bei
|
||||
Dateien mit einer 1.1.x.x-Revision vermieden werden. Das
|
||||
Repository kann sich durch Änderungen einzelner Zeichen
|
||||
dramatisch aufblähen.</para>
|
||||
<quote>Kosmetik</quote>-Kategorie einzuordnen und sollten vermieden
|
||||
werden. Das Repository kann sich durch Änderungen einzelner
|
||||
Zeichen dramatisch aufblähen.</para>
|
||||
</note>
|
||||
|
||||
<para>Die eingebettete
|
||||
<application>Tcl</application>-Programmiersprache soll als
|
||||
Beispiel dienen, wie dieses Modell funktioniert:</para>
|
||||
<sect2 id="vendor-imports-cvs">
|
||||
|
||||
<title>Herstellerimports mit CVS</title>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> enthält den
|
||||
<para>Das <application>file</application>-Werkzeug soll als Beispiel
|
||||
dienen, wie dieses Modell funktioniert:</para>
|
||||
|
||||
<para><filename>src/contrib/file</filename> enthält den
|
||||
Quelltext so, wie vom Maintainer dieses Pakets bereitgestellt.
|
||||
Teile, die unter FreeBSD gänzlich unnutzbar sind,
|
||||
können entfernt werden. Im Fall von Tcl wurden die
|
||||
Unterverzeichnisse <filename>mac</filename>,
|
||||
<filename>win</filename> und <filename>compat</filename>
|
||||
vor dem Import entfernt.</para>
|
||||
Teile, die unter &os; gänzlich unnutzbar sind, können entfernt
|
||||
werden. Im Fall von &man.file.1; wurde u.a. das Unterverzeichnis
|
||||
<filename>python</filename> und Dateien mit dem Präfix
|
||||
<filename>lt</filename> vor dem Import entfernt.</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> enthält ein
|
||||
<filename>Makefile</filename> im
|
||||
<application>bmake</application>-Stil, das die Regeln des
|
||||
Standard-Makefiles <filename>bsd.lib.mk</filename> nutzt, um
|
||||
die Bibliothek zu erstellen und die Dokumentation zu
|
||||
<para><filename>src/lib/libmagic</filename> enthält ein
|
||||
<filename>Makefile</filename> im <application>bmake</application>-Stil,
|
||||
das die Regeln des Standard-Makefiles <filename>bsd.lib.mk</filename>
|
||||
nutzt, um die Bibliothek zu erstellen und die Dokumentation zu
|
||||
installieren.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> enthält ein
|
||||
<filename>Makefile</filename> im
|
||||
<application>bmake</application>-Stil, welches das
|
||||
<command>tclsh</command>-Programm erstellt und installiert,
|
||||
<para><filename>src/usr.bin/file</filename> enthält ein
|
||||
<filename>Makefile</filename> im <application>bmake</application>-Stil,
|
||||
welches das <command>file</command>-Programm erstellt und installiert,
|
||||
ebenso die dazugehörigen Manualpages, welche die Regeln von
|
||||
<filename>bsd.prog.mk</filename> nutzen.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> enthält
|
||||
einige Shell-Skripten, die hilfreich sein können, wenn die
|
||||
Tcl-Software aktualisiert werden soll. Diese sind nicht Teil
|
||||
des Erstellens und der Installation der Software.</para>
|
||||
|
||||
<para>Das Entscheidende ist hier das
|
||||
<filename>src/contrib/tcl</filename>-Verzeichnis, welches nach
|
||||
<filename>src/contrib/file</filename>-Verzeichnis, welches nach
|
||||
den folgenden Regeln erstellt wird: Es muss den
|
||||
Quelltext aus dem Original enthalten (ohne
|
||||
RCS-Schlüsselworte und im korrekten CVS-Herstellerzweig)
|
||||
mit so wenig FreeBSD-spezifischen Änderungen wie
|
||||
<acronym>RCS</acronym>-Schlüsselworte und im korrekten
|
||||
Herstellerzweig) mit so wenig FreeBSD-spezifischen Änderungen wie
|
||||
möglich. Sollte es Zweifel geben, wie hier zu verfahren
|
||||
ist, unbedingt zuerst nachfragen und
|
||||
nicht auf gut Glück etwas probieren in der vagen
|
||||
Hoffnung, dass es <quote>irgendwie tut</quote>. CVS verzeiht
|
||||
keine Fehler beim Importieren und ein hoher Arbeitsaufwand
|
||||
wäre die Folge, um diesen großen Fehler wieder
|
||||
wettzumachen.</para>
|
||||
ist, unbedingt zuerst nachfragen und nicht auf gut Glück etwas
|
||||
probieren in der vagen Hoffnung, dass es
|
||||
<quote>irgendwie funktioniert</quote>.</para>
|
||||
|
||||
<para>Aufgrund der eingangs schon erwähnten Einschränkungen
|
||||
bei CVS-Herstellerzweigen ist es erforderlich,
|
||||
dass <quote>offizielle</quote> Fehlerbehebungen vom Hersteller
|
||||
in die Originalquellen der Distribution einfließen und als
|
||||
Resultat wieder in den Herstellerzweig importiert werden.
|
||||
Offizielle Fehlerbehebungen sollten nie direkt in FreeBSD
|
||||
eingepflegt und <quote>committet</quote> werden, da dies
|
||||
bei Herstellerzweigen ist es erforderlich, dass <quote>offizielle</quote>
|
||||
Fehlerbehebungen vom Hersteller in die Originalquellen der Distribution
|
||||
einfließen und als Resultat wieder in den Herstellerzweig
|
||||
importiert werden. Offizielle Fehlerbehebungen sollten nie direkt in
|
||||
FreeBSD eingepflegt und <quote>committet</quote> werden, da dies
|
||||
den Herstellerzweig zerstören würde und der Import
|
||||
von zukünftigen Versionen wäre um ein Vielfaches
|
||||
schwerer, da es zu Konflikten kommen würde.</para>
|
||||
|
|
@ -216,7 +235,7 @@
|
|||
einzuchecken, sodass es für zukünftige Maintainer
|
||||
verfügbar ist.</para>
|
||||
|
||||
<para>Im Verzeichnis <filename>src/contrib/tcl</filename> sollte
|
||||
<para>Im Verzeichnis <filename>src/contrib/file</filename> sollte
|
||||
eine Datei mit dem Namen <filename>FREEBSD-upgrade</filename>
|
||||
hinzugefügt werden und sie sollte den Stand wie folgt
|
||||
anzeigen:</para>
|
||||
|
|
@ -243,51 +262,312 @@
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Importieren Sie jedoch <filename>FREEBSD-upgrade</filename>
|
||||
nicht mit den beigesteuerten Quelldateien. Stattdessen sollten
|
||||
Sie <command>cvs add FREEBSD-upgrade ; cvs ci</command> nach
|
||||
dem initialen Import nutzen. Ein Beispiel von
|
||||
<filename>src/contrib/cpio</filename> sehen Sie hier:</para>
|
||||
<para>Ein Beispielinhalt von
|
||||
<filename>src/contrib/groff/FREEBSD-upgrade</filename> ist hier
|
||||
aufgelistet:</para>
|
||||
|
||||
<programlisting>$FreeBSD: src/contrib/groff/FREEBSD-upgrade,v 1.5.12.1 2005/11/15 22:06:18 ru Exp $
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
the files in this directory via patches and a cvs commit.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
To upgrade to a newer version of groff, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
2. Use the command:
|
||||
cvs import -m 'Virgin import of FSF groff v<version>' \
|
||||
src/contrib/groff FSF v<version>
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
For example, to do the import of version 1.19.2, I typed:
|
||||
cvs import -m 'Virgin import of FSF groff v1.19.2' \
|
||||
src/contrib/groff FSF v1_19_2
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
3. Follow the instructions printed out in step 2 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
To make local changes to groff, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the FSF branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
All local changes should be submitted to Werner Lemberg <wl@gnu.org> or
|
||||
Ted Harding <ted.harding@nessie.mcc.ac.uk> for inclusion in the next
|
||||
vendor release.
|
||||
|
||||
obrien@FreeBSD.org - 30 March 1997</programlisting>
|
||||
ru@FreeBSD.org - 20 October 2005</programlisting>
|
||||
|
||||
|
||||
<para>Eine weitere Möglichkeit ist es, eine Liste von Dateien, die
|
||||
nicht enthalten sein sollen zu pflegen, was besonders dann sehr hilfreich
|
||||
sein kann, wenn die Liste ziemlich gross oder kompliziert ist bzw.
|
||||
Imports sehr häufig stattfinden. Durch erstellen einer Datei namens
|
||||
<filename>FREEBSD-Xlist</filename> im gleichen Verzeichnis, in welches
|
||||
das Herstellerverzeichnis importiert werden soll, die eine Liste von
|
||||
auszuschliessenden Dateinamen-Mustern pro Zeile enthält, können
|
||||
zukünftige Imports folgendermassen durchgeführt werden:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>tar</command> <option>-X</option> <filename>FREEBSD-Xlist</filename> <option>-xzf</option> <filename><replaceable>vendor-source.tgz</replaceable></filename></userinput></screen>
|
||||
|
||||
<para>Als Beispiel einer <filename>FREEBSD-Xlist</filename>-Datei wird
|
||||
hier diejenige von <filename>src/contrib/tcsh</filename> gezeigt:</para>
|
||||
|
||||
<programlisting>*/BUGS
|
||||
*/config/a*
|
||||
*/config/bs2000
|
||||
*/config/bsd
|
||||
*/config/bsdreno
|
||||
*/config/[c-z]*
|
||||
*/tests
|
||||
*/win32</programlisting>
|
||||
|
||||
<note>
|
||||
<para>Bitte importieren Sie weder <filename>FREEBSD-upgrade</filename>
|
||||
noch <filename>FREEBSD-Xlist</filename> mit den beigesteuerten
|
||||
Quellen. Stattdessen sollten Sie diese Dateien nach dem initialen
|
||||
Import hinzufügen.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="vendor-import-svn">
|
||||
<sect2info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Dag-Erling</firstname>
|
||||
<surname>Smørgrav</surname>
|
||||
<contrib>Beigetragen von </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect2info>
|
||||
|
||||
<title>Herstellerimports mit SVN</title>
|
||||
|
||||
<para>Dieser Abschnitt beschreibt die Prozedur für Herstellerimports
|
||||
mit <application>Subversion</application> im Detail.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<title>Vorbereiten des Quellbaums</title>
|
||||
|
||||
<para>Wenn dies Ihr erster Import nach dem Wechsel zu
|
||||
<acronym>SVN</acronym> ist, sollen Sie den Herstellerbaum
|
||||
aufräumen, verflachen und die Merge-Historie in den Hauptzweig
|
||||
vorbereiten. Falls das nicht Ihr erster Import ist, können
|
||||
Sie diesen Schritt ohne Probleme überspringen.</para>
|
||||
|
||||
<para>Während der Konvertierung von <acronym>CVS</acronym> zu
|
||||
<acronym>SVN</acronym> wurden Herstellerzweige mit der gleichen
|
||||
Struktur wie der Hauptzweig importiert. Beispielsweise wurden die
|
||||
<application>foo</application> Herstellerquellen in
|
||||
<filename>vendor/<replaceable>foo</replaceable>/dist/contrib/<replaceable>foo</replaceable></filename>
|
||||
abgelegt, jedoch ist dies unpraktisch und zwecklos. Was wir wirklich
|
||||
wollen, ist dass die Herstellerquellen direkt in
|
||||
<filename>vendor/<replaceable>foo</replaceable>/dist</filename>
|
||||
liegen, beispielsweise so:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>cd</command> <filename class="directory">vendor/<replaceable>foo</replaceable>/dist/contrib/<replaceable>foo</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>svn move</command> $(svn list) <filename>../..</filename></userinput>
|
||||
&prompt.user; <userinput><command>cd</command> <filename>../..</filename></userinput>
|
||||
&prompt.user; <userinput><command>svn remove</command> <filename>contrib</filename></userinput>
|
||||
&prompt.user; <userinput><command>svn propdel</command> <option>-R</option> svn:mergeinfo</userinput>
|
||||
&prompt.user; <userinput><command>svn commit</command></userinput></screen>
|
||||
|
||||
<para>Beachten Sie, dass das <literal>propdel</literal>-Bit notwendig
|
||||
ist, da mit Subversion 1.5 automatisch
|
||||
<literal>svn:mergeinfo</literal> zu jedem Verzeichnis
|
||||
hinzugefügt wird, das Sie kopieren oder verschieben. In diesem
|
||||
Fall brauchen Sie diese Informationen nicht, da Sie nichts in den
|
||||
Zweig mergen werden, den Sie gelöscht haben.</para>
|
||||
|
||||
<note>
|
||||
<para>Sie werden wahrscheinlich die Tags genauso verflachen wollen.
|
||||
Die Prozedur dafür ist die selbe. Wenn Sie dies tun, sollten
|
||||
Sie den Commit bis zum Schluss aufschieben.</para>
|
||||
</note>
|
||||
|
||||
<para>Prüfen Sie den <filename>dist</filename>-Baum und
|
||||
führen Sie alle nötigen Aufräumarbeiten durch, die Sie
|
||||
für sinnvoll erachten. Sie werden möglicherweise die
|
||||
Erweiterung von Schlüsselwörtern deaktivieren wollen, da
|
||||
dies auf unmodifizierten Quellen keinen Sinn ergibt. In machen
|
||||
Fällen kann dies sogar schädlich sein.<para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>svn propdel</command> svn:keywords <option>-R</option> <filename>.</filename></userinput>
|
||||
&prompt.user; <userinput><command>svn commit</command></userinput></screen>
|
||||
|
||||
<para>Bootstrappen der <literal>svn:mergeinfo</literal> auf dem
|
||||
Zielverzeichnis (des Hauptzweiges) auf die Revision die mit der
|
||||
letzten Änderung, die im Herstellerzweig vor dem Import der
|
||||
neuen Quellen durchgeführt wurde, korrespondiert, wird ebenso
|
||||
benötigt:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>cd</command> <filename>head/contrib/<replaceable>foo</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>svn merge</command> <option>--record-only</option> <replaceable>svn_base</replaceable>/vendor/<replaceable>foo</replaceable>/dist@<replaceable>12345678</replaceable> <filename>.</filename></userinput>
|
||||
&prompt.user; <userinput><command>svn commit</command></userinput></screen>
|
||||
|
||||
<para>Dabei entspricht <replaceable>svn_base</replaceable> dem
|
||||
Basisverzeichnis Ihres <acronym>SVN</acronym>-Repositories, z.B.
|
||||
<literal>svn+ssh://svn.FreeBSD.org/base</literal>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>Neue Quellen importieren</title>
|
||||
|
||||
<para>Bereiten Sie einen kompletten, sauberen Baum mit
|
||||
Herstellerquellen vor. Mit <acronym>SVN</acronym> können wir
|
||||
eine komplette Distribution in dem Herstellerzweig aufbewahren, ohne
|
||||
den Hauptzweig aufzublähen. Importieren Sie alles, aber mergen
|
||||
Sie nur das, was wirklich benötigt wird.</para>
|
||||
|
||||
<para>Beachten Sie, dass Sie alle Dateien, die seit dem letzten
|
||||
Herstellerimport hinzugefügt wurden, auch einbeziehen und
|
||||
diejenigen, welche entfernt wurden, auch löschen
|
||||
müssen. Um dies zu bewerkstelligen, sollten Sie sortierte
|
||||
Listen der Bestandteile des Herstellerbaums und von den Quellen,
|
||||
Sie die vorhaben zu importieren, vorbereiten:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>cd</command> <filename>vendor/<replaceable>foo</replaceable>/dist</filename></userinput>
|
||||
&prompt.user; <userinput><command>svn list</command> <option>-R</option> | <command>grep</command> <option>-v</option> '/$' | <command>sort</command> > <filename>../<replaceable>old</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>cd</command> <filename>../<replaceable>foo-9.9</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>find</command> <filename>.</filename> <option>-type</option> f | <command>cut</command> <option>-c</option> 3- | <command>sort</command> > <filename>../<replaceable>new</replaceable></filename></userinput></screen>
|
||||
|
||||
<para>Mit diesen beiden Dateien, wird Ihnen das folgende Kommando alle
|
||||
Dateien auflisten, die entfernt wurden (nur die Dateien in
|
||||
<filename><replaceable>old</replaceable></filename>):</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>comm <option>-23</option> <filename>../<replaceable>old</replaceable></filename> <filename>../<replaceable>new</replaceable></filename></command></userinput></screen>
|
||||
|
||||
<para>Der folgende Befehl wird die hinzugefügten Dateien auflisten
|
||||
(nur diejenigen Dateien in
|
||||
<filename><replaceable>new</replaceable></filename>):</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>comm <option>-13</option> <filename>../<replaceable>old</replaceable></filename> <filename>../<replaceable>new</replaceable></filename></command></userinput></screen>
|
||||
|
||||
<para>Wir führen dies nun zusammen:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>cd</command> <filename class="directory">vendor/<replaceable>foo</replaceable>/<replaceable>foo-9.9</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>tar</command> cf - <filename>.</filename> | <command>tar</command> xf - <option>-C</option> <filename>../dist</filename></userinput>
|
||||
&prompt.user; <userinput><command>cd</command> <filename class="directory">../dist</filename></userinput>
|
||||
&prompt.user; <userinput><command>comm</command> <option>-23</option> <filename>../<replaceable>old</replaceable></filename> <filename>../<replaceable>new</replaceable></filename> | <command>xargs</command> svn remove</userinput>
|
||||
&prompt.user; <userinput><command>comm</command> <option>-13</option> <filename>../<replaceable>old</replaceable></filename> <filename>../<replaceable>new</replaceable></filename> | <command>xargs</command> svn add</userinput></screen>
|
||||
|
||||
<warning>
|
||||
<para>Wenn in der neuen Version neue Verzeichnisse hinzugekommen
|
||||
sind, wird dieser letzte Befehl fehlschlagen. Sie müssen
|
||||
diese Verzeichnisse hinzufügen und anschliessend den Befehl
|
||||
erneut ausführen. Genauso müssen Sie Verzeichnisse, die
|
||||
entfernt wurden, händisch löschen.</para>
|
||||
</warning>
|
||||
|
||||
<para>Prüfen Sie die Eigenschaften jeder neuen Datei:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Alle Textdateien sollten <literal>svn:eol-style</literal> auf
|
||||
den Wert <literal>native</literal> gesetzt haben.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Alle Binärdateien sollten
|
||||
<literal>svn:mime-type</literal> auf
|
||||
<literal>application/octet-stream</literal> gesetzt haben,
|
||||
ausser es existiert ein passenderer Medientyp.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ausführbare Dateien sollten
|
||||
<literal>svn:executable</literal> auf <literal>*</literal>
|
||||
gesetzt haben.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Es sollten keine anderen Eigenschaften auf den Dateien im
|
||||
Baum gesetzt sein.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>Sie sind bereit, zu committen, jedoch sollten Sie zuerst die
|
||||
Ausgabe von <command>svn stat</command> und <command>svn
|
||||
diff</command> überprüfen, um sicher zu gehen, dass alles
|
||||
in Ordnung ist.</para>
|
||||
</note>
|
||||
|
||||
<para>Sobald Sie den die neue Release-Version des Herstellers
|
||||
committed haben, sollten Sie Ihn für zukünftige Referenzen
|
||||
taggen. Die beste und schnellste Methode ist, dies direkt im
|
||||
Repository zu tun:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>svn copy</command> <filename><replaceable>svn_base</replaceable>/vendor/<replaceable>foo</replaceable>/dist</filename> <filename><replaceable>svn_base</replaceable>/vendor/<replaceable>foo</replaceable>/<replaceable>9.9</replaceable></filename></userinput></screen>
|
||||
|
||||
<para>Um den neuen Tag zu bekommen, brauchen Sie nur ihre Arbeitskopie
|
||||
von <filename>vendor/<replaceable>foo</replaceable></filename> zu
|
||||
aktualisieren.</para>
|
||||
|
||||
<note>
|
||||
<para>Wenn Sie lieber die Kopie in der ausgecheckten Kopie
|
||||
durchführen wollen, vergessen Sie nicht, die generierte
|
||||
<literal>svn:mergeinfo</literal> wie oben beschrieben zu
|
||||
entfernen.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>Mit <emphasis>-HEAD</emphasis> mergen</title>
|
||||
|
||||
<para>Nachdem Sie Ihren Import vorbereitet haben, wird es Zeit zu
|
||||
mergen. Die Option <option>--accept=postpone</option> weist
|
||||
<acronym>SVN</acronym> an, noch keine merge-Konflikte
|
||||
aufzulösen, weil wir uns um diese manuell kümmern
|
||||
werden:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>cd</command> <filename class="directory">head/contrib/<replaceable>foo</replaceable></filename></userinput>
|
||||
&prompt.user; <userinput><command>svn update</command></userinput>
|
||||
&prompt.user; <userinput><command>svn merge</command> <option>--accept=postpone</option> <filename><replaceable>svn_base</replaceable>/vendor/<replaceable>foo</replaceable>/dist</filename></userinput></screen>
|
||||
|
||||
<para>Lösen Sie die Konflikte und stellen Sie sicher, dass alle
|
||||
Dateien, die im Herstellerzweig hinzugefügt oder entfernt
|
||||
wurden, auch sauber im Hauptzweig hinzugefügt bzw. gelöscht
|
||||
wurden. Es ist immer ratsam, diese Unterschiede gegen den
|
||||
Herstellerbaum zu prüfen:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput><command>svn diff</command> <option>--no-diff-deleted</option> <option>--old=</option><filename><replaceable>svn_base</replaceable>/vendor/<replaceable>foo</replaceable>/dist</filename> <option>--new=</option><filename>.</filename></userinput></screen>
|
||||
|
||||
<para>Die Option <option>--no-diff-deleted</option> weist
|
||||
<acronym>SVN</acronym> an, keine Dateien zu prüfen, die sich
|
||||
zwar im Herstellerbaum, aber nicht im Hauptzweig befinden.</para>
|
||||
|
||||
<note>
|
||||
<para>Bei <acronym>SVN</acronym> gibt es das Konzept von innerhalb
|
||||
und ausserhalb des Herstellerbaums nicht. Wenn eine Datei, die
|
||||
zuvor eine lokale Änderung hatte, aber nun keine mehr
|
||||
besitzt, entfernen Sie einfach das was übrig ist, wie &os;
|
||||
Versionstags, damit diese nicht länger in den diffs gegen
|
||||
den Herstellerbaum erscheinen.</para>
|
||||
</note>
|
||||
|
||||
<para>Wenn irgendwelche Änderungen notwendig sind, um die Welt
|
||||
mit den neuen Quellen zu bauen, machen Sie diese jetzt und testen
|
||||
Sie diese bis Sie sicher sind, dass alles korrekt gebaut wird und
|
||||
richtig funktionert.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>Commit</title>
|
||||
|
||||
<para>Nun sind Sie bereit für den Commit. Stellen Sie sicher,
|
||||
dass Sie alles in einem einzigen Schritt durchführen.
|
||||
Idealerweise sollten Sie alle diese Schritte in einem sauberen Baum
|
||||
durchgeführt haben. Falls dies der Fall ist, können Sie
|
||||
einfach aus dem obersten Verzeichnis dieses Baums committen. Dies
|
||||
ist der beste Weg, um Überraschungen zu vermeiden. Wenn Sie
|
||||
dies korrekt durchführen, wird der Baum atomar von einem
|
||||
konsistenten Zustand mit dem alten Code in einen neuen konsistenten
|
||||
Zustand mit dem neuen Code überführt.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-encumbered">
|
||||
|
|
@ -325,8 +605,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
|
|||
<para>Jede belastende Datei braucht eine spezielle
|
||||
Genehmigung vom <ulink
|
||||
url="&url.base;/administration.html#t-core">Core-Team</ulink>,
|
||||
bevor diese in das CVS-Repository aufgenommen
|
||||
werden darf.</para>
|
||||
bevor diese in das Repository aufgenommen werden darf.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -498,7 +777,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
|
|||
die Shared-Library-Versionsnummer nur einmal zwischen den
|
||||
Releases zu ändern. Weiterhin ist es vorgeschrieben, die
|
||||
Major-Version der Shared-Libraries nur bei Major-OS-Releases zu
|
||||
ändern (beispielsweise von 3.0 auf 4.0). Wenn Sie also eine
|
||||
ändern (beispielsweise von 6.0 auf 7.0). Wenn Sie also eine
|
||||
Änderung an einer Systembibliothek vornehmen, die eine neue
|
||||
Versionsnummer benötigt, überprüfen Sie die
|
||||
Commit-Logs des <filename>Makefile</filename>s. Es liegt in der
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.767 2011/03/08 12:21:18 jkois Exp $
|
||||
$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.768 2011/03/27 15:30:15 bcr Exp $
|
||||
|
||||
basiert auf: 1.1133
|
||||
basiert auf: 1.1134
|
||||
|
||||
-->
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ $FreeBSDde: de-docproj/books/faq/book.sgml,v 1.767 2011/03/08 12:21:18 jkois Exp
|
|||
</collab>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.767 2011/03/08 12:21:18 jkois Exp $</pubdate>
|
||||
<pubdate>$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.768 2011/03/27 15:30:15 bcr Exp $</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1995</year>
|
||||
|
|
@ -4650,10 +4650,12 @@ calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)</sc
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Das als Open Source verfügbare Office-Paket
|
||||
<para>Die als Open Source verfügbaren Office-Pakete
|
||||
<application><ulink
|
||||
url="http://www.openoffice.org">OpenOffice.org</ulink></application>
|
||||
läuft nativ unter &os;. Die um zusätzliche
|
||||
und <application><ulink
|
||||
url="http://www.libreoffice.org">LibreOffice</ulink></application>
|
||||
laufen nativ unter &os;. Die um zusätzliche
|
||||
Funktionen erweiterte kommerzielle OpenOffice.org-Version
|
||||
<application><ulink
|
||||
url="http://www.oracle.com/us/products/applications/open-office/index.html">
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/config/chapter.sgml,v 1.148 2010/12/18 08:49:58 jkois Exp $
|
||||
basiert auf: 1.245
|
||||
$FreeBSDde: de-docproj/books/handbook/config/chapter.sgml,v 1.149 2011/03/27 15:50:46 bcr Exp $
|
||||
basiert auf: 1.246
|
||||
-->
|
||||
|
||||
<chapter id="config-tuning">
|
||||
|
|
@ -151,8 +151,9 @@
|
|||
extrahieren die Paketwerkzeuge eine vorübergehende Kopie der
|
||||
Pakete unter <filename class="directory">/var/tmp</filename>. Die
|
||||
Installation grosser Softwarepakete wie
|
||||
<application>Firefox</application> oder
|
||||
<application>Openoffice</application> kann sich wegen zu wenig
|
||||
<application>Firefox</application>,
|
||||
<application>Openoffice</application> oder
|
||||
<application>LibreOffice</application> kann sich wegen zu wenig
|
||||
Speicherplatz in <filename class="directory">/var/tmp</filename>
|
||||
als trickreich herausstellen.</para>
|
||||
</note>
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/desktop/chapter.sgml,v 1.86 2011/02/25 09:28:51 jkois Exp $
|
||||
basiert auf: 1.101
|
||||
$FreeBSDde: de-docproj/books/handbook/desktop/chapter.sgml,v 1.88 2011/03/27 17:46:34 bcr Exp $
|
||||
basiert auf: 1.104
|
||||
-->
|
||||
|
||||
<chapter id="desktop">
|
||||
|
|
@ -68,7 +68,8 @@
|
|||
<para>Büroanwendungen (<application>KOffice</application>,
|
||||
<application>AbiWord</application>,
|
||||
<application>The GIMP</application>,
|
||||
<application>OpenOffice.org</application>)</para>
|
||||
<application>OpenOffice.org</application>,
|
||||
<application>LibreOffice</application>)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -563,6 +564,16 @@
|
|||
<entry><application>&jdk;</application>,
|
||||
<application>Mozilla</application></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><application>LibreOffice</application></entry>
|
||||
<entry>etwas hoch</entry>
|
||||
<entry>enorm</entry>
|
||||
<entry><application>Gtk+</application>,
|
||||
<application>KDE</application>/
|
||||
<application>GNOME</application> oder
|
||||
<application>&jdk;</application></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
|
@ -769,7 +780,99 @@
|
|||
Befehl starten:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>openoffice.org</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>LibreOffice</title>
|
||||
<indexterm>
|
||||
<primary>
|
||||
<application>LibreOffice</application>
|
||||
</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>office suite</primary>
|
||||
<secondary>
|
||||
<application>LibreOffice</application>
|
||||
</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para><application>LibreOffice</application> ist ein als freie Software
|
||||
verfügbares Office-Paket, welches von <ulink
|
||||
url="http://www.documentfoundation.org/">The Document
|
||||
Foundation</ulink> entwickelt wird, das mit anderen
|
||||
grossen Office-Paketen kompatibel ist und auf einer Vielzahl von
|
||||
Plattformen lauffähig ist. Es ist ein Fork von
|
||||
<application>OpenOffice.org</application> unter neuem Namen, der alle
|
||||
notwendigen Anwendungen in einem kompletten Büroanwendungspaket
|
||||
enthält: eine Textverarbeitung, eine Tabellenkalkulation, ein
|
||||
Präsentationsmanager, ein Zeichenprogramm, ein
|
||||
Datenbankmanagementprogramm und ein Werkzeug zum Erstellen und
|
||||
Bearbeiten von mathematischen Formeln. Es steht in einer Reihe von
|
||||
Sprachen zur Verfügung; die Internationalisierung wurde auf die
|
||||
Oberfläche, Rechtschreibkorrektur und die Wörterbücher
|
||||
ausgeweitet.</para>
|
||||
|
||||
<para>Das Textverarbeitungsprogramm von
|
||||
<application>LibreOffice</application> benutzt ein natives
|
||||
XML-Dateiformat für erhöhte Portabilität und
|
||||
Flexibilität. Die Tabellenkalkulation enthält eine
|
||||
Makrosprache und kann mit externen Datenbanken Verbindungen herstellen.
|
||||
<application>LibreOffice</application> ist bereits stabil genug und
|
||||
läuft nativ auf &windows;, Linux, &os; und &macos; X.
|
||||
Weitere Informationen zu <application>LibreOffice</application>
|
||||
können auf der <ulink
|
||||
url="http://www.libreoffice.org/">LibreOffice Webseite</ulink>
|
||||
abgerufen werden.</para>
|
||||
|
||||
<para>Um <application>LibreOffice</application> als Paket zu
|
||||
installieren, geben Sie folgenden Befehl ein:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pkg_add -r libreoffice</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>Dies sollte funktionieren, wenn Sie eine -RELEASE-Version von
|
||||
&os; einsetzen.</para>
|
||||
</note>
|
||||
|
||||
<para>Sobald das Paket installiert ist, geben Sie das folgende Kommando
|
||||
ein, um <application>LibreOffice</application> zu starten:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>libreoffice</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>Während des ersten Starts werden Sie ein paar Fragen
|
||||
gestellt bekommen und es wird ein Verzeichnis
|
||||
<filename class="directory">.libreoffice</filename> in Ihrem
|
||||
Heimatverzeichnis erstellt.</para>
|
||||
</note>
|
||||
|
||||
<para>Wenn die <application>LibreOffice</application>-Pakete nicht
|
||||
verfügbar sind, haben Sie immer noch die Möglichkeit, den
|
||||
Port zu verwenden. Jedoch müssen Sie bedenken, dass dies eine
|
||||
Menge Speicherplatz benötigt und viel Zeit in Anspruch nimmt, bis
|
||||
der Port fertig gebaut ist.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /usr/ports/editors/libreoffice</userinput>
|
||||
&prompt.root; <userinput>make install clean</userinput></screen>
|
||||
|
||||
<note>
|
||||
<para>Wenn Sie eine Version in Ihrer Sprache bauen möchten,
|
||||
ersetzen Sie das vorhergehende Kommando mit dem folgenden:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>make LOCALIZED_LANG=<replaceable>ihre_Sprache</replaceable> install clean</userinput></screen>
|
||||
|
||||
<para>Sie müssen <replaceable>ihre_Sprache</replaceable> mit dem
|
||||
richtigen ISO-Code für ihre Sprache ersetzen. Eine Liste von
|
||||
unterstützten Sprachcodes sind im <filename>Makefile</filename>
|
||||
des Ports als <maketarget>pre-fetch</maketarget>-Target
|
||||
verfügbar.</para>
|
||||
</note>
|
||||
|
||||
<para>Sobald dies abgeschlossen ist, kann
|
||||
<application>LibreOffice</application> mit dem folgenden Befehl
|
||||
gestartet werden:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>libreoffice</userinput></screen>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -1219,6 +1322,13 @@
|
|||
<entry><filename role="package">editors/openoffice.org-3</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><application>LibreOffice</application></entry>
|
||||
<entry><literal>libreoffice</literal></entry>
|
||||
<entry><filename
|
||||
role="package">editors/libreoffice</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><application>&acrobat.reader;</application></entry>
|
||||
<entry><literal>acroread</literal></entry>
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/disks/chapter.sgml,v 1.180 2011/03/13 19:26:47 bcr Exp $
|
||||
basiert auf: 1.306
|
||||
$FreeBSDde: de-docproj/books/handbook/disks/chapter.sgml,v 1.181 2011/03/23 13:00:29 jkois Exp $
|
||||
basiert auf: 1.307
|
||||
-->
|
||||
|
||||
<chapter id="disks">
|
||||
|
|
@ -4756,7 +4756,7 @@ Device 1K-blocks Used Avail Capacity
|
|||
Stellen Sie bei Systemen, bei denen nur das Allernötigste
|
||||
vorhanden sein soll, sicher, dass dieses Modul zur Verfügung
|
||||
steht. Als Alternative lässt sich die
|
||||
<acronym>GEOM_GATE</acronym>-Unterstützung direkt in den Kernel
|
||||
<literal>GEOM_GATE</literal>-Unterstützung direkt in den Kernel
|
||||
statisch einbauen, indem Sie die folgende Zeile zu Ihrer
|
||||
Kernelkonfigurationsdatei hinzufügen:</para>
|
||||
|
||||
|
|
@ -4779,7 +4779,7 @@ Device 1K-blocks Used Avail Capacity
|
|||
</itemizedlist>
|
||||
|
||||
<para>Das folgende Beispiel beschreibt, wie man zwei Knoten als
|
||||
<literal>master</literal>-<literal>slave</literal> /
|
||||
<literal>master</literal>-<literal>slave</literal> /
|
||||
<literal>primary</literal>-<literal>secondary</literal> mittels
|
||||
<acronym>HAST</acronym> konfiguriert, um Daten zwischen diesen beiden
|
||||
auszutauschen. Die Knoten werden als
|
||||
|
|
@ -4878,7 +4878,7 @@ Device 1K-blocks Used Avail Capacity
|
|||
zurückgemeldet wird, ist etwas schief gegangen. Zu diesem
|
||||
Zeitpunkt hat die Synchronisation zwischen den beiden Knoten bereits
|
||||
begonnen. Die Synchronisation ist beendet, wenn das Kommando
|
||||
<command>hastctl status</command> meldet, dass die
|
||||
<command>hastctl status</command> meldet, dass die
|
||||
<literal>dirty</literal>-Bereiche 0 Bytes betragen.</para>
|
||||
|
||||
<para>Der letzte Schritt ist, ein Dateisystem auf dem
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/introduction/chapter.sgml,v 1.66 2010/12/18 09:39:29 jkois Exp $
|
||||
basiert auf: 1.139
|
||||
$FreeBSDde: de-docproj/books/handbook/introduction/chapter.sgml,v 1.67 2011/03/27 15:44:48 bcr Exp $
|
||||
basiert auf: 1.140
|
||||
-->
|
||||
|
||||
<chapter id="introduction">
|
||||
|
|
@ -873,7 +873,7 @@
|
|||
7.0-RELEASE, das erste Release des 7.X-Zweiges, wurde im
|
||||
Februar 2008 veröffentlicht. Das aktuelle
|
||||
&rel2.current;-RELEASE (dem keine weiteren RELENG_7-Versionen
|
||||
folgen werden) erschien im Januar 2009.</para>
|
||||
folgen werden) erschien im Februar 2011.</para>
|
||||
|
||||
<para>Im August 2009 wurde der RELENG_8-Zweig angelegt.
|
||||
8.0-RELEASE, das erste Release des 8.X-Zweiges, erschien im
|
||||
|
|
@ -1093,7 +1093,7 @@
|
|||
Aufgabe des Core-Team, genauso wie die Rekrutierung
|
||||
neuer Mitglieder für das Core-Team, im Falle, dass
|
||||
Altmitglieder aus dem Projekt aussteigen. Das
|
||||
derzeitige Core-Team wurde im Juli 2008 aus einem Kreis
|
||||
derzeitige Core-Team wurde im Juli 2010 aus einem Kreis
|
||||
kandidierender Committer gewählt. Wahlen
|
||||
werden alle zwei Jahre abgehalten.</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue