[SCM] live-manual branch, debian-next, updated. debian/3.0_a11-1-34-gd965646
chals
chals at altorricon.com
Sat Apr 14 14:09:26 UTC 2012
The following commit has been merged in the debian-next branch:
commit d965646fb8326e1fe70688da36377bec5c17d095
Author: chals <chals at altorricon.com>
Date: Sat Apr 14 16:11:11 2012 +0200
Fixing markup of debian packages using italics.
diff --git a/manual/en/about_manual.ssi b/manual/en/about_manual.ssi
index 3f96203..87b47ae 100644
--- a/manual/en/about_manual.ssi
+++ b/manual/en/about_manual.ssi
@@ -28,7 +28,7 @@ _* *{Host system}*: The environment used to create the live system.
_* *{Target system}*: The environment used to run the live system.
-_* *{live-boot}*: A collection of scripts used to boot live systems. live-boot was formerly a part of live-initramfs.
+_* *{live-boot}*: A collection of scripts used to boot live systems. live-boot was formerly a part of /{live-initramfs}/.
_* *{live-build}*: A collection of scripts used to build customized Debian Live systems. live-build was formerly known as /{live-helper}/, and even earlier known as /{live-package}/.
@@ -207,7 +207,7 @@ code{
To submit a translation for a new language, follow these three steps:
-_* Translate the about_manual.ssi.pot, about_project.ssi.pot and index.html.in.pot files to your language with your favourite editor (such as poedit). Send translated files to the mailing list. Once we have reviewed your submission, we will add the new language to the manual (providing the po files) and will enable it in the autobuild.
+_* Translate the about_manual.ssi.pot, about_project.ssi.pot and index.html.in.pot files to your language with your favourite editor (such as /{poedit}/). Send translated files to the mailing list. Once we have reviewed your submission, we will add the new language to the manual (providing the po files) and will enable it in the autobuild.
_* Once the new language is added, you can randomly start translating all po files in #{manual/po/}#.
diff --git a/manual/en/user_basics.ssi b/manual/en/user_basics.ssi
index 69ebe87..f3d39c5 100644
--- a/manual/en/user_basics.ssi
+++ b/manual/en/user_basics.ssi
@@ -80,7 +80,7 @@ code{
The first time you boot your live media, whether CD, DVD, USB key, or PXE boot, some setup in your computer's BIOS may be needed first. Since BIOSes vary greatly in features and key bindings, we cannot get into the topic in depth here. Some BIOSes provide a key to bring up a menu of boot devices at boot time, which is the easiest way if it is available on your system. Otherwise, you need to enter the BIOS configuration menu and change the boot order to place the boot device for the live system before your normal boot device.
-Once you've booted the media, you are presented with a boot menu. If you just press enter here, the system will boot using the default entry, #{Live}# and default options. For more information about boot options, see the "help" entry in the menu and also the #{live-boot}# and #{live-config}# man pages found within the live system.
+Once you've booted the media, you are presented with a boot menu. If you just press enter here, the system will boot using the default entry, #{Live}# and default options. For more information about boot options, see the "help" entry in the menu and also the live-boot and live-config man pages found within the live system.
Assuming you've selected #{Live}# and booted a default desktop live image, after the boot messages scroll by, you should be automatically logged into the #{user}# account and see a desktop, ready to use. If you've booted a console-only image, such as #{standard}# or #{rescue}# flavour prebuilt images, you should be automatically logged in on the console to the #{user}# account and see a shell prompt, ready to use.
@@ -100,9 +100,9 @@ Provided you can work within these constraints, survey the available VM software
3~testing-iso-with-qemu Testing an ISO image with QEMU
-The most versatile VM in Debian is QEMU. If your processor has hardware support for virtualization, use the #{qemu-kvm}# package; the #{qemu-kvm}# package description briefly lists the requirements.
+The most versatile VM in Debian is QEMU. If your processor has hardware support for virtualization, use the /{qemu-kvm}/ package; the /{qemu-kvm}/ package description briefly lists the requirements.
-First, install #{qemu-kvm}# if your processor supports it. If not, install #{qemu}#, in which case the program name is #{qemu}# instead of #{kvm}# in the following examples. The #{qemu-utils}# package is also valuable for creating virtual disk images with #{qemu-img}#.
+First, install /{qemu-kvm}/ if your processor supports it. If not, install /{qemu}/, in which case the program name is /{qemu}/ instead of #{kvm}# in the following examples. The /{qemu-utils}/ package is also valuable for creating virtual disk images with #{qemu-img}#.
code{
@@ -188,7 +188,7 @@ code{
3~using-usb-extra-space Using the space left on a USB stick
-To use the remaining free space after copying #{binary.img}# to a USB stick, use a partitioning tool such as #{gparted}# or #{parted}# to create a new partition on the stick. The first partition will be used by the Debian Live system.
+To use the remaining free space after copying #{binary.img}# to a USB stick, use a partitioning tool such as /{gparted}/ or /{parted}/ to create a new partition on the stick. The first partition will be used by the Debian Live system.
code{
@@ -290,7 +290,7 @@ and fill in the new tftp server directory when being asked about it.
Once the guest computer has downloaded and booted a Linux kernel and loaded its initrd, it will try to mount the Live filesystem image through a NFS server.
-You need to install the #{nfs-kernel-server}# package.
+You need to install the /{nfs-kernel-server}/ package.
Then, make the filesystem image available through NFS by adding a line like the following to #{/etc/exports}#:
@@ -318,7 +318,7 @@ To make our life easier, we can use virtualization. There are two solutions.
3~ Qemu
-_* Install #{qemu}#, #{bridge-utils}#, #{sudo}#.
+_* Install /{qemu}/, /{bridge-utils}/, /{sudo}/.
Edit #{/etc/qemu-ifup}#:
diff --git a/manual/en/user_customization-contents.ssi b/manual/en/user_customization-contents.ssi
index 4c00e5a..0b4546c 100644
--- a/manual/en/user_customization-contents.ssi
+++ b/manual/en/user_customization-contents.ssi
@@ -20,7 +20,7 @@ Please see {Terms}#terms for more information about the distinction between the
Chroot local includes can be used to add or replace files in the chroot/Live filesystem so that they may be used in the Live system. A typical use is to populate the skeleton user directory (#{/etc/skel}#) used by the Live system to create the live user's home directory. Another is to supply configuration files that can be simply added or replaced in the image without processing; see {Live/chroot local hooks}#live-chroot-local-hooks if processing is needed.
-To include files, simply add them to your #{config/includes.chroot}# directory. This directory corresponds to the root directory (#{/}#) of the live system. For example, to add a file #{/var/www/index.html}# in the live system, use:
+To include files, simply add them to your #{config/includes.chroot}# directory. This directory corresponds to the root directory #{/}# of the live system. For example, to add a file #{/var/www/index.html}# in the live system, use:
code{
@@ -90,4 +90,4 @@ To run commands in the binary stage, create a hook script with a #{.binary}# suf
Files in the #{config/preseed/}# directory suffixed with #{.preseed}# followed by the stage (#{.chroot}# or #{.binary}#) are considered to be debconf preseed files and are installed by live-build using #{debconf-set-selections}# during the corresponding stage.
-For more information about debconf, please see debconf(7) in the #{debconf}# package.
+For more information about debconf, please see #{debconf(7)}# in the /{debconf}/ package.
diff --git a/manual/en/user_customization-overview.ssi b/manual/en/user_customization-overview.ssi
index ee85e0e..87005fb 100644
--- a/manual/en/user_customization-overview.ssi
+++ b/manual/en/user_customization-overview.ssi
@@ -18,7 +18,7 @@ Within each of these stages, there is a particular sequence in which commands ar
2~ Supplement lb config with files
-Although #{lb config}# does create a skeletal configuration in the config/ directory, to accomplish your goals, you may need to provide additional files in subdirectories of config/. Depending on where the files are stored in the configuration, they may be copied into the live system's filesystem or into the binary image filesystem, or may provide build-time configurations of the system that would be cumbersome to pass as command-line options. You may include things such as custom lists of packages, custom artwork, or hook scripts to run either at build time or at boot time, boosting the already considerable flexibility of debian-live with code of your own.
+Although #{lb config}# creates a skeletal configuration in the config/ directory, to accomplish your goals, you may need to provide additional files in subdirectories of config/. Depending on where the files are stored in the configuration, they may be copied into the live system's filesystem or into the binary image filesystem, or may provide build-time configurations of the system that would be cumbersome to pass as command-line options. You may include things such as custom lists of packages, custom artwork, or hook scripts to run either at build time or at boot time, boosting the already considerable flexibility of debian-live with code of your own.
2~ Customization tasks
diff --git a/manual/en/user_customization-packages.ssi b/manual/en/user_customization-packages.ssi
index 5dadbc0..f9812a4 100644
--- a/manual/en/user_customization-packages.ssi
+++ b/manual/en/user_customization-packages.ssi
@@ -2,13 +2,13 @@
1~customizing-package-installation Customizing package installation
-Perhaps the most basic customization of a Debian live system is the selection of packages to be included in the image. This chapter guides you through the various build-time options to customize live-build's installation of packages. The broadest choices influencing which packages are available to install in the image are the distribution and archive areas. To ensure decent download speeds, you should choose a nearby distribution mirror. You can also add your own repositories for backports, experimental or custom packages, or include packages directly as files. You can define your own lists of packages to include, use live-build's predefined lists, use #{tasksel}# tasks, or a combination of all three. Finally, a number of options give some control over apt, or if you prefer, aptitude, at build time when packages are installed. You may find these handy if you use a proxy, want to disable installation of recommended packages to save space, or need to control which versions of
packages are installed via APT pinning, to name a few possibilities.
+Perhaps the most basic customization of a Debian live system is the selection of packages to be included in the image. This chapter guides you through the various build-time options to customize live-build's installation of packages. The broadest choices influencing which packages are available to install in the image are the distribution and archive areas. To ensure decent download speeds, you should choose a nearby distribution mirror. You can also add your own repositories for backports, experimental or custom packages, or include packages directly as files. You can define your own lists of packages to include, use live-build's predefined lists, use /{tasksel}/ tasks, or a combination of all three. Finally, a number of options give some control over /{apt}/, or if you prefer, /{aptitude}/, at build time when packages are installed. You may find these handy if you use a proxy, want to disable installation of recommended packages to save space, or need to control which vers
ions of packages are installed via APT pinning, to name a few possibilities.
2~ Package sources
3~ Distribution, archive areas and mode
-The distribution you choose has the broadest impact on which packages are available to include in your live image. Specify the codename, which defaults to #{wheezy}# for the wheezy version of live-build. Any current distribution carried in the Debian archive may be specified by its codename here. (See {Terms}#terms for more details.) The #{--distribution}# option not only influences the source of packages within the archive, but also instructs live-build to behave as needed to build each supported distribution. For example, to build against the *{unstable}* release, sid, specify:
+The distribution you choose has the broadest impact on which packages are available to include in your live image. Specify the codename, which defaults to wheezy for the wheezy version of live-build. Any current distribution carried in the Debian archive may be specified by its codename here. (See {Terms}#terms for more details.) The #{--distribution}# option not only influences the source of packages within the archive, but also instructs live-build to behave as needed to build each supported distribution. For example, to build against the *{unstable}* release, sid, specify:
code{
@@ -121,7 +121,7 @@ To make a binary stage list, place a file suffixed with #{.list.binary}# in #{co
The package lists that are included with live-build make extensive use of includes. Refer to these in the #{/usr/share/live/build/package-lists/}# directory, as they serve as good examples of how to write your own lists.
-For example, to make a list that includes the predefined #{gnome}# list plus iceweasel, create #{config/package-lists/my.list.chroot}# with the following contents:
+For example, to make a list that includes the predefined #{gnome}# list plus /{iceweasel}/, create #{config/package-lists/my.list.chroot}# with the following contents:
code{
@@ -144,7 +144,7 @@ code{
}code
-You may test for any one of a number of values, e.g. to install #{memtest86+}# if either #{--architectures i386}# or #{--architectures amd64}# is specified:
+You may test for any one of a number of values, e.g. to install /{memtest86+}/ if either #{--architectures i386}# or #{--architectures amd64}# is specified:
code{
@@ -262,7 +262,7 @@ You can configure APT through a number of options applied only at build time. (A
3~choosing-apt-or-aptitude Choosing apt or aptitude
-You can elect to use either #{apt}# or #{aptitude}# when installing packages at build time. Which utility is used is governed by the #{--apt}# argument to #{lb config}#. Choose the method implementing the preferred behaviour for package installation, the notable difference being how missing packages are handled.
+You can elect to use either /{apt}/ or /{aptitude}/ when installing packages at build time. Which utility is used is governed by the #{--apt}# argument to #{lb config}#. Choose the method implementing the preferred behaviour for package installation, the notable difference being how missing packages are handled.
_* #{apt}#: With this method, if a missing package is specified, the package installation will fail. This is the default setting.
@@ -335,7 +335,7 @@ $ lb config --distribution wheezy
}code
-Negative pin priorities will prevent a package from being installed, as in the case where you do not want a package that is recommended by another package. Suppose you are building an LXDE image using #{--package-lists lxde}# option, but don't want the user prompted to store wifi passwords in the keyring. This list includes #{gdm}#, which depends on #{gksu}#, which in turn recommends #{gnome-keyring}#. So you want to omit the recommended #{gnome-keyring}# package. This can be done by adding the following stanza to #{config/chroot_apt/preferences}#:
+Negative pin priorities will prevent a package from being installed, as in the case where you do not want a package that is recommended by another package. Suppose you are building an LXDE image using #{--package-lists lxde}# option, but don't want the user prompted to store wifi passwords in the keyring. This list includes /{gdm}/, which depends on /{gksu}/, which in turn recommends /{gnome-keyring}/. So you want to omit the recommended /{gnome-keyring}/ package. This can be done by adding the following stanza to #{config/chroot_apt/preferences}#:
code{
diff --git a/manual/en/user_examples.ssi b/manual/en/user_examples.ssi
index 2f5a644..3aadc00 100644
--- a/manual/en/user_examples.ssi
+++ b/manual/en/user_examples.ssi
@@ -109,7 +109,7 @@ code{
}code
-First, #{--architectures i386}# ensures that on our #{amd64}# build system, we build a 32-bit version suitable for use on most machines. Second, we use #{--linux-flavours 686-pae}# because we don't anticipate using this image on much older systems. Third, we've chosen the #{lxde}# package list to give us a minimal desktop. And finally, we have added two initial favourite packages: #{iceweasel}# and #{xchat}#.
+First, #{--architectures i386}# ensures that on our #{amd64}# build system, we build a 32-bit version suitable for use on most machines. Second, we use #{--linux-flavours 686-pae}# because we don't anticipate using this image on much older systems. Third, we've chosen the /{lxde}/ package list to give us a minimal desktop. And finally, we have added two initial favourite packages: /{iceweasel}/ and /{xchat}/.
Now, build the image:
diff --git a/manual/en/user_managing_a_configuration.ssi b/manual/en/user_managing_a_configuration.ssi
index aad6304..7342877 100644
--- a/manual/en/user_managing_a_configuration.ssi
+++ b/manual/en/user_managing_a_configuration.ssi
@@ -12,7 +12,7 @@ For example, when the distribution is first set, many 'dependent' variables are
A second, related problem is that if you run #{lb config}# and then upgrade to a new version of live-build that has changed one of the variable names, you will discover this only by manual review of the variables in your #{config/*}# files, which you will then need to use to set the appropriate option again.
-All of this would be a terrible nuisance if it weren't for auto/* scripts, simple wrappers to the #{lb config}#, #{lb build}# and #{lb clean}# commands that are designed to help you manage your configuration. Simply create an auto/config script containing #{lb config}# command with all desired options, and an auto/clean that removes the files containing configuration variable values, and each time you run #{lb config}# and #{lb clean}#, these files will be executed. This will ensure that your configuration is kept internally consistent from one revision to the next and from one live-build release to the next (though you will still have to take care and read the documentation when you upgrade live-build and make adjustments as needed).
+All of this would be a terrible nuisance if it weren't for auto/* scripts, simple wrappers to the #{lb config}#, #{lb build}# and #{lb clean}# commands that are designed to help you manage your configuration. Simply create an auto/config script containing #{lb config}# command with all desired options, and an auto/clean that removes the files containing configuration variable values, and each time you run #{lb config}# and #{lb clean}#, these files will be executed. This will ensure that your configuration is kept internally consistent from one revision to the next and from one live-build release to the next (Although you will still have to take care and read the documentation when you upgrade live-build and make adjustments as needed).
2~ Example auto scripts
diff --git a/manual/en/user_overview.ssi b/manual/en/user_overview.ssi
index 2da8890..df8abb4 100644
--- a/manual/en/user_overview.ssi
+++ b/manual/en/user_overview.ssi
@@ -16,7 +16,7 @@ _* The scripts have a central location for configuring their operation. In /{deb
_* The scripts are independent - that is to say, it is always safe to run each command.
-Unlike /{debhelper}/, live-build contains a tool to generate a skeleton configuration directory, #{lb config}#. This could be considered to be similar to tools such as #{dh-make}#. For more information about #{lb config}#, please see {The lb config command}#lb-config.
+Unlike /{debhelper}/, live-build contains a tool to generate a skeleton configuration directory, #{lb config}#. This could be considered to be similar to tools such as /{dh-make}/. For more information about #{lb config}#, please see {The lb config command}#lb-config.
The remainder of this section discusses the three most important commands:
--
live-manual
More information about the debian-live-changes
mailing list