[SCM] live-manual branch, debian-next, updated. debian/3.0_a8-1-7-g03b373b
skizzhg
skizzhg at gmx.com
Mon Oct 10 21:18:39 UTC 2011
The following commit has been merged in the debian-next branch:
commit 03b373bd77462d01a1e239c57a91c680c43cf176
Author: skizzhg <skizzhg at gmx.com>
Date: Mon Oct 10 23:18:50 2011 +0200
Updating user_installation, italian translation.
diff --git a/manual/de/_sisu/.empty b/manual/de/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/de/_sisu/image/.empty b/manual/de/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/de/_sisu/sisurc.yml b/manual/de/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/de/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/de/_sisu/skin/doc/skin_debian-live.rb b/manual/de/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/de/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/de/about_manual.ssi b/manual/de/about_manual.ssi
deleted file mode 100644
index c15a1a8..0000000
--- a/manual/de/about_manual.ssi
+++ /dev/null
@@ -1,270 +0,0 @@
-:B~ About this manual
-
-1~about-manual About this manual
-
-The main goal of this manual is to serve as a single access point to all
-documentation related to the Debian Live project. While it is primarily
-focused on helping you build a live system and not on end-user topics, an
-end-user may find some useful information in these sections: {The
-Basics}#the-basics covers preparing images to be booted from media or the
-network, and {Customizing run time
-behaviours}#customizing-run-time-behaviours describes some options that may
-be specified at the boot prompt, such as selecting a keyboard layout and
-locale, and using persistence.
-
-Some of the commands mentioned in the text must be executed with superuser
-privileges which can be obtained by becoming the root user via #{su}# or by
-using #{sudo}#. To distinguish between commands which may be executed by an
-unprivileged user and those requiring superuser privileges, commands are
-prepended by #{$}# or #{#}# respectively. This symbol is not a part of the
-command.
-
-2~ For the impatient
-
-While we believe that everything in this manual is important to at least
-some of our users, we realize it is a lot of material to cover and that you
-may wish to experience early success using the software before delving into
-the details. Therefore, we have provided three tutorials in the
-{Examples}#examples section designed to teach you image building and
-customization basics. Read {Using the examples}#using-the-examples first,
-followed by {Tutorial 1: A standard image}#tutorial-1, {Tutorial 2: A web
-browser utility}#tutorial-2 and finally {Tutorial 3: A personalized
-image}#tutorial-3. By the end of these tutorials, you will have a taste of
-what can be done with Debian Live. We encourage you to return to more
-in-depth study of the manual, perhaps next reading {The basics}#the-basics,
-skimming or skipping {Building a netboot image}#building-netboot-image, and
-finishing by reading the {Customization overview}#customization-overview and
-the chapters that follow it. By this point, we hope you are thoroughly
-excited by what can be done with Debian Live and motivated to read the rest
-of the manual, cover-to-cover.
-
-2~terms Terms
-
-_* *{Live system}*: An operating system that can boot without installation
-to a hard drive. Live systems do not alter local operating system(s) or
-file(s) already installed on the computer hard drive unless instructed to do
-so. Live systems are typically booted from media such as CDs, DVDs or USB
-sticks. Some may also boot over the network.
-
-_* *{Debian Live}*: The Debian sub-project which maintains the live-boot,
-live-build, live-config, and live-manual packages.
-
-_* *{Debian Live system}*: A live system that uses software from the Debian
-operating system that may be booted from CDs, DVDs, USB sticks, over the
-network (via netboot images), and over the Internet (via boot parameter
-#{fetch=URL}#).
-
-_* *{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-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.
-
-_* *{live-config}*: A collection of scripts used to configure a live system
-during the boot process. live-config was formerly a part of live-initramfs.
-
-_* *{live-manual}*: This document is maintained in a package called
-live-manual.
-
-_* *{Debian Installer (d-i)}*: The official installation system for the
-Debian distribution.
-
-_* *{Boot parameters}*: Parameters that can be entered at the bootloader
-prompt to influence the kernel or live-config.
-
-_* *{chroot}*: The chroot program, #{chroot(8)}#, enables us to run
-different instances of the GNU/Linux environment on a single system
-simultaneously without rebooting.
-
-_* *{Binary image}*: A file containing the live system, such as binary.iso
-or binary.img.
-
-_* *{Target distribution}*: The distribution upon which your live system
-will be based. This can differ from the distribution of your host system.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Debian codenames for
-releases. At the time of writing, Squeeze is the current *{stable}* release
-and Wheezy is the current *{testing}* release. Sid will always be a synonym
-for the *{unstable}* release. Throughout the manual, we tend to use
-codenames for the releases, as that is what is supported by the tools
-themselves.
-
-The *{stable}* distribution contains the latest officially released
-distribution of Debian. The *{testing}* distribution is the staging area for
-the next *{stable}* release. A major advantage of using this distribution is
-that it has more recent versions of software relative to the *{stable}*
-release. The *{unstable}* distribution is where active development of Debian
-occurs. Generally, this distribution is run by developers and those who like
-to live on the edge.
-
-2~ Authors
-
-A list of authors (in alphabetical order):
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Contributing to this document
-
-This manual is intended as a community project and all proposals for
-improvements and contributions are extremely welcome. The preferred way to
-submit a contribution is to send it to the mailing list. Please see the
-section {Contact}#contact for more information.
-
-When submitting a contribution, please clearly identify its copyright holder
-and include the licensing statement. Note that to be accepted, the
-contribution must be licensed under the same license as the rest of the
-document, namely, GPL version 3 or later.
-
-The sources for this manual are maintained using the Git version control
-system. You can check out the latest copy by executing:
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Prior to submission of your contribution, please preview your work. To
-preview the live-manual, ensure the packages needed for building are
-installed by executing:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-You may build the live-manual from the top level directory of your Git
-checkout by executing:
-
-code{
-
- $ make build
-
-}code
-
-Since it takes a while to build the manual in all supported languages, you
-may find it convenient when proofing to build for only one language, e.g. by
-executing:
-
-code{
-
- $ make build LANGUAGES=en
-
-}code
-
-3~ Applying patches
-
-Anyone can directly commit to the repository. However, we ask you to send
-bigger changes to the mailing list to discuss them first. To push to the
-repository, you must follow this procedure:
-
-_* Fetch the public commit key:
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Add the following section to your openssh-client config:
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Check out a clone of the manual through ssh:
-
-code{
-
- $ git clone git at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Note that you should commit any changes on the debian-next branch, not on
-the debian branch.
-
-_* After editing the files in #{manual/en/}#, please call the 'commit'
-target in the top level directory to sanitize the files and update the
-translation files:
-
-code{
-
- $ make commit
-
-}code
-
-_* After sanitizing, commit the changes. Write commit messages that consist
-of full, useful sentences in English, starting with a capital letter and
-ending with a full stop. Usually, these will start with the form
-'Fixing/Adding/Removing/Correcting/Translating', e.g.
-
-code{
-
- $ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Push the commit to the server:
-
-code{
-
- $ git push
-
-}code
-
-3~ Translation
-
-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.
-
-_* Once the new language is added, you can randomly start translating all po
-files in #{manual/po/}#.
-
-_* Don't forget you need #{make commit}# to ensure the translated manuals
-are updated from the po files, before #{git commit -a}# and #{git push}#.
diff --git a/manual/de/about_project.ssi b/manual/de/about_project.ssi
deleted file mode 100644
index 677a730..0000000
--- a/manual/de/about_project.ssi
+++ /dev/null
@@ -1,107 +0,0 @@
-:B~ About the Debian Live Project
-
-1~about-project About the Debian Live Project
-
-2~ Motivation
-
-3~ What is wrong with current live systems
-
-When Debian Live was initiated, there were already several Debian based live
-systems available and they are doing a great job. From the Debian
-perspective most of them have one or more of the following disadvantages:
-
-_* They are not Debian projects and therefore lack support from within
-Debian.
-
-_* They mix different distributions, e.g. *{testing}* and *{unstable}*.
-
-_* They support i386 only.
-
-_* They modify the behaviour and/or appearance of packages by stripping them
-down to save space.
-
-_* They include packages from outside of the Debian archive.
-
-_* They ship custom kernels with additional patches that are not part of
-Debian.
-
-_* They are large and slow due to their sheer size and thus not suitable for
-rescue issues.
-
-_* They are not available in different flavours, e.g. CDs, DVDs, USB-stick
-and netboot images.
-
-3~ Why create our own live system?
-
-Debian is the Universal Operating System: Debian has a live system to show
-around and to accurately represent the Debian system with the following main
-advantages:
-
-_* It would be a subproject of Debian.
-
-_* It reflects the (current) state of one distribution.
-
-_* It runs on as many architectures as possible.
-
-_* It consists of unchanged Debian packages only.
-
-_* It does not contain any packages that are not in the Debian archive.
-
-_* It uses an unaltered Debian kernel with no additional patches.
-
-2~ Philosophy
-
-3~ Only unchanged packages from Debian "main"
-
-We will only use packages from the Debian repository in the "main"
-section. The non-free section is not part of Debian and therefore cannot be
-used for official live system images.
-
-We will not change any packages. Whenever we need to change something, we
-will do that in coordination with its package maintainer in Debian.
-
-As an exception, our own packages such as live-boot, live-build or
-live-config may temporarily be used from our own repository for development
-reasons (e.g. to create development snapshots). They will be uploaded to
-Debian on a regular basis.
-
-3~ No package configuration of the live system
-
-In this phase we will not ship or install sample or alternative
-configurations. All packages are used in their default configuration as they
-are after a regular installation of Debian.
-
-Whenever we need a different default configuration, we will do that in
-coordination with its package maintainer in Debian.
-
-A system for configuring packages is provided using debconf in #{lb config}#
-(use --preseed FILE) allowing custom configured packages to be installed in
-your custom produced Debian Live images, but for official live images only
-default configuration will be used. For more information, please see
-{Customization overview}#customization-overview.
-
-Exception: There are a few essential changes needed to bring a live system
-to life (e.g. configuring pam to allow empty passwords). These essential
-changes have to be kept as minimal as possible and should be merged within
-the Debian repository if possible.
-
-2~contact Contact
-
-_* *{Mailing list}*: The primary contact for the project is the mailing list
-at http://lists.debian.org/debian-live/. You can email the list directly by
-addressing your mail to debian-live at lists.debian.org. The list archives are
-available at http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: A number of users and developers are present in the #debian-live
-channel on irc.debian.org (OFTC). When asking a question on IRC, please be
-patient for an answer. If no answer is forthcoming, please email the mailing
-list.
-
-_* *{BTS}*: The Debian Bug Tracking System (BTS) contains details of bugs
-reported by users and developers. Each bug is given a number, and is kept on
-file until it is marked as having been dealt with. For more information,
-please see {Reporting bugs}#bugs.
-
-_* *{Wiki}*: The Debian Live wiki at http://wiki.debian.org/DebianLive is a
-place to gather information, discuss applied technologies, and document
-frameworks of Debian Live systems that go beyond the scope of this document.
diff --git a/manual/de/index.html.in b/manual/de/index.html.in
deleted file mode 100644
index 68f1f56..0000000
--- a/manual/de/index.html.in
+++ /dev/null
@@ -1,60 +0,0 @@
-<html>
-
-<head>
- <title>Debian Live Projekt</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Debian Live Handbuch</h2>
-
- <p>
- Fehler, Vergessenes, Patches und Vorschläge können an unsere Mailing Liste
-unter <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>
-(englischspraching) gemeldet werden. Informationen wie man <a
-href="html/about-manual.html#how-to-contribute">zum Handbuch beitragen</a>
-kann, können im Handbuch gefunden werden.
- </p>
-
- <h3>Verfügbare Formate</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">mehrere Seiten</a>, <a
-href="html/live-manual.html">einzelne Seite</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 Hochformat</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 Querformat</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">Letter Hochformat</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">Letter Querformat</a></li>
- <li><a href="txt/live-manual.txt">Text</a></li>
- </ul>
-
- <p>
- Letzte Änderung: @DATE_CHANGE@<br />
- Letzte Aktualisierung: @DATE_BUILD@
- </p>
-
- <h3>Quellen</h3>
-
- <p>
- Die Quellen dieses Handbuches sind in einem <a
-href="http://git.or.cz/">Git</a> Repository auf live.debian.net verfügbar.
- </p>
-
- <ul>
- <li>Browse: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Rechtliche Hinweise</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/de/live-manual.ssm b/manual/de/live-manual.ssm
deleted file mode 100644
index f8faa5e..0000000
--- a/manual/de/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Debian Live Manual
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.<br><br>This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.<br><br>You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. <br><br>The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file.
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ About
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ User
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Project
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Examples
-
-<< user_examples.ssi
diff --git a/manual/de/project_bugs.ssi b/manual/de/project_bugs.ssi
deleted file mode 100644
index b0c34fc..0000000
--- a/manual/de/project_bugs.ssi
+++ /dev/null
@@ -1,198 +0,0 @@
-B~ Reporting bugs
-
-1~bugs Reporting bugs
-
-Debian Live is far from being perfect, but we want to make it as close as
-possible to perfect - with your help. Do not hesitate to report a bug: it is
-better to fill a report twice than never. However, this chapter includes
-recommendations how to file good bug reports.
-
-For the impatient:
-
-_* Always check first the image status updates on our homepage at
-http://live.debian.net/ for known issues.
-
-_* Always try to reproduce the bug with the *{most recent versions}* of
-live-build, live-boot, and live-config before submitting a bug report.
-
-_* Try to give *{as specific information as possible}* about the bug. This
-includes (at least) the version of live-build, live-boot, and live-config
-used and the distribution of the live system you are building.
-
-2~ Known issues
-
-Because Debian *{testing}* and Debian *{unstable}* distributions are a
-moving target, when you specify either as the target system distribution, a
-successful build may not always be possible.
-
-% FIXME:
-
-If this causes too much difficulty for you, do not build a system based on
-*{testing}* or *{unstable}*, but rather, use *{stable}*. live-build does
-always default to the *{stable}* release.
-
-Currently known issues are listed under the section 'status' on our homepage
-at http://live.debian.net/.
-
-It is out of the scope of this manual to train you to correctly identify and
-fix problems in packages of the development distributions, however, there
-are two things you can always try: If a build fails when the target
-distribution is *{testing}*, try *{unstable}*. If *{unstable}* does not work
-either, revert to *{testing}* and pin the newer version of the failing
-package from *{unstable}* (see {APT pinning}#apt-pinning for details).
-
-2~ Rebuild from scratch
-
-To ensure that a particular bug is not caused by an uncleanly built system,
-please always rebuild the whole live system from scratch to see if the bug
-is reproducible.
-
-2~ Use up-to-date packages
-
-Using outdated packages can cause significant problems when trying to
-reproduce (and ultimately fix) your problem. Make sure your build system is
-up-to-date and any packages included in your image are up-to-date as well.
-
-2~collect-information Collect information
-
-Please provide enough information with your report. At least include the
-exact version of live-build version where the bug is encountered and steps
-to reproduce it. Please use common sense and include other relevant
-information if you think that it might help in solving the problem.
-
-To make the most out of your bug report, we require at least the following
-information:
-
-_* Architecture of the host system
-
-_* Version of live-build on the host system
-
-_* Version of live-boot on the live system
-
-_* Version of live-config on the live system
-
-_* Version of #{debootstrap}# and/or #{cdebootstrap}# on the host system
-
-_* Architecture of the live system
-
-_* Distribution of the live system
-
-_* Version of the kernel on the live system
-
-You can generate a log of the build process by using the #{tee}# command. We
-recommend doing this automatically with an #{auto/build}# script; (see
-{Managing a configuration}#managing-a-configuration for details).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-At boot time, live-boot stores a log in #{/var/log/live.log}# (or
-#{/var/log/live-boot.log}#).
-
-Additionally, to rule out other errors, it is always a good idea to tar up
-your #{config/}# directory and upload it somewhere (do *{not}* send it as an
-attachment to the mailing list), so that we can try to reproduce the errors
-you encountered. If this is difficult (e.g. due to size) you can use the
-output of #{lb config --dump}# which produces a summary of your config tree
-(i.e. lists files in subdirectories of #{config/}# but does not include
-them).
-
-Remember to send in any logs that were produced with English locale
-settings, e.g. run your live-build commands with a leading #{LC_ALL=C}# or
-#{LC_ALL=en_US}#.
-
-2~ Isolate the failing case if possible
-
-If possible, isolate the failing case to the smallest possible change that
-breaks. It is not always easy to do this, so if you can't manage it for your
-report, don't worry. However, if you plan your development cycle well, using
-small enough change sets per iteration, you may be able to isolate the
-problem by constructing a simpler 'base' configuration that closely matches
-your actual configuration plus just the broken change set added to it. If
-you have a hard time sorting out which of your changes broke, it may be that
-you are including too much in each change set and should develop in smaller
-increments.
-
-2~ Use the correct package to report the bug against
-
-Where does the bug appear?
-
-3~ At build time whilst bootstrapping
-
-live-build first bootstraps a basic Debian system with #{debootstrap}# or
-#{cdebootstrap}#. Depending on the bootstrapping tool used and the Debian
-distribution it is bootstrapping, it may fail. If a bug appears here, check
-if the error is related to a specific Debian package (most likely), or if it
-is related to bootstrapping tool itself.
-
-In both cases, this is not a bug in Debian Live, but rather in Debian itself
-which we can not fix this directly. Please report such a bug against the
-bootstrapping tool or the failing package.
-
-3~ At build time whilst installing packages
-
-live-build installs additional packages from the Debian archive and
-depending on the Debian distribution used and the daily archive state, it
-can fail. If a bug appears here, check if the error is also reproducible on
-a normal system.
-
-If this is the case, this is not a bug in Debian Live, but rather in Debian
-- please report it against the failing package. Running #{debootstrap}#
-separately from the Live system build or running #{lb bootstrap --debug}#
-will give you more information.
-
-Also, if you are using a local mirror and/or any of sort of proxy and you
-are experiencing a problem, please always reproduce it first by
-bootstrapping from an official mirror.
-
-3~ At boot time
-
-If your image does not boot, please report it to the mailing list together
-with the information requested in {Collect
-information}#collect-information. Do not forget to mention, how/when the
-image failed, in Qemu, Virtualbox, VMWare or real hardware. If you are using
-a virtualization technology of any kind, please always run it on real
-hardware before reporting a bug. Providing a screenshot of the failure is
-also very helpful.
-
-3~ At run time
-
-If a package was successfully installed, but fails while actually running
-the Live system, this is probably a bug in Debian Live. However,
-
-2~ Do the research
-
-Before filing the bug, please search the web for the particular error
-message or symptom you are getting. As it is highly unlikely that you are
-the only person experiencing a particular problem, there is always a chance
-that it has been discussed elsewhere, and a possible solution, patch, or
-workaround has been proposed.
-
-You should pay particular attention to the Debian Live mailing list, as well
-as the homepage, as these are likely to contain the most up-to-date
-information. If such information exists, always include the references to it
-in your bug report.
-
-In addition, you should check the current bug lists for live-build,
-live-boot, and live-config to see whether something similar has been
-reported already.
-
-2~ Where to report bugs
-
-The Debian Live project keeps track of all bugs in the Debian Bug Tracking
-System (BTS). For information on how to use the system, please see
-http://bugs.debian.org/. You can also submit the bugs by using the
-#{reportbug}# command from the package with the same name.
-
-In general, you should report build time errors against the live-build
-package, boot time errors against live-boot, and run time errors against
-live-config. If you are unsure of which package is appropriate or need more
-help before submitting a bug report, please send a message to the mailing
-list and we will help you to figure it out.
-
-Please note that bugs found in distributions derived from Debian (such as
-Ubuntu and others) should *{not}* be reported to the Debian BTS unless they
-can be also reproduced on a Debian system using official Debian packages.
diff --git a/manual/de/project_coding-style.ssi b/manual/de/project_coding-style.ssi
deleted file mode 100644
index c4a9b86..0000000
--- a/manual/de/project_coding-style.ssi
+++ /dev/null
@@ -1,144 +0,0 @@
-B~ Coding Style
-
-1~coding-style Coding Style
-
-This chapter documents the coding style used in live-boot and others.
-
-2~ Compatibility
-
-_* Don't use syntax or semantics that are unique to the Bash shell. For
-example, the use of array constructs.
-
-_* Only use the POSIX subset - for example, use $(foo) over `foo`.
-
-_* You can check your scripts with 'sh -n' and 'checkbashisms'.
-
-2~ Indenting
-
-_* Always use tabs over spaces.
-
-2~ Wrapping
-
-_* Generally, lines are 80 chars at maximum.
-
-_* Use the "Linux style" of line breaks:
-
-Bad:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Good:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* The same holds for functions:
-
-Bad:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Good:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variables
-
-_* Variables are always in capital letters.
-
-_* Variables that used in #{lb config}# always start with #{LB_}# prefix.
-
-_* Internal temporary variables in live-build should start with the
-#{\_LB_}# prefix.
-
-_* Local variables start with live-build #{\_\_LB_}# prefix.
-
-_* Variables in connection to a boot parameter in live-config start with
-#{LIVE_}#.
-
-_* All other variables in live-config start with #{_}# prefix.
-
-_* Use braces around variables; e.g. write #{${FOO}}# instead of #{$FOO}#.
-
-_* Always protect variables with quotes to respect potential whitespaces:
-write #{"${FOO}"}# not #{${FOO}}#.
-
-_* For consistency reasons, always use quotes when assigning values to
-variables:
-
-Bad:
-
-code{
-
- FOO=bar
-
-}code
-
-Good:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* If multiple variables are used, quote the full expression:
-
-Bad:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Good:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Miscellaneous
-
-_* Use "#{|}#" (without the surround quotes) as a seperator in calls to sed,
-e.g. "#{sed -e 's|foo|bar|'}#" (without "").
-
-_* Don't use the #{test}# command for comparisons or tests, use "#{[}#"
-"#{]}#" (without ""); e.g. "#{if [ -x /bin/foo ]; ...}#" and not "#{if test
--x /bin/foo; ...}#".
-
-_* Use #{case}# wherever possible over #{test}#, as it's easier to read and
-faster in execution.
diff --git a/manual/de/project_procedures.ssi b/manual/de/project_procedures.ssi
deleted file mode 100644
index 552749e..0000000
--- a/manual/de/project_procedures.ssi
+++ /dev/null
@@ -1,139 +0,0 @@
-B~ Procedures
-
-1~procedures Procedures
-
-This chapter documents the procedures within the Debian Live project for
-various tasks that need cooperation with other teams in Debian.
-
-2~ Udeb Uploads
-
-Before commiting releases of a udeb in d-i svn, one has to call:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Major Releases
-
-Releasing a new stable major version of Debian includes a lot of different
-teams working together to make it happen. At some point, the Live team comes
-in and builds live system images. The requirements to do this are:
-
-_* A mirror containing the released versions for the debian, debian-security
-and debian-volatile archive which the debian-live buildd can access.
-
-_* The names of the image need to be known
-(e.g. debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* The packagelists need to have been updated.
-
-_* The data from debian-cd needs to be synced (udeb exclude lists).
-
-_* The includes from debian-cd needs to be synced (README.*, doc/*, etc.).
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-2~ Point Releases
-
-_* Again, we need updated mirror of debian, debian-security and
-debian-volatile.
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-_* Send announcement mail.
-
-3~ Point release announcement template
-
-An annoucement mail for point releases can be generated using the template
-below and the following command:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-Please check the mail carefully before sending and pass it to others for
-proof-reading.
-
-code{
-
- Debian Live images for Debian GNU/Linux %major% updated
-
- The Debian Live project is pleased to announce the availability of
- updated Live images for its stable distribution Debian GNU/Linux %major%
- (codename "%codename%").
-
- The images are available for download at:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- This update incorporates the changes made in the %minor% point release,
- which adds corrections for security problems to the stable release
- along with a few adjustments for serious problems. A full list of the
- changes may be viewed at:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
- It also includes the following Live-specific changes:
-
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
-
-
- URLs
- ----
-
- Download location of updated images:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Debian Live project homepage:
-
- <http://live.debian.net/>
-
- The current stable distribution:
-
- <http://ftp.debian.org/debian/dists/stable>
-
- stable distribution information (release notes, errata etc.):
-
- <http://www.debian.org/releases/stable/>
-
- Security announcements and information:
-
- <http://www.debian.org/security/>
-
-
- About Debian
- -------------
-
- The Debian Project is an association of Free Software developers who
- volunteer their time and effort in order to produce the completely free
- operating system Debian GNU/Linux.
-
-
- About Debian Live
- -----------------
-
- Debian Live is an official sub-project of Debian which produces Debian
- systems that do not require a classical installer. Images are available
- for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
- filesystem images for booting directly from the internet.
-
-
- Contact Information
- -------------------
-
- For further information, please visit the Debian Live web pages at
- <http://live.debian.net/> or alternatively send mail to
- <debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/de/user_basics.ssi b/manual/de/user_basics.ssi
deleted file mode 100644
index 4429660..0000000
--- a/manual/de/user_basics.ssi
+++ /dev/null
@@ -1,528 +0,0 @@
-:B~ The basics
-
-1~the-basics The basics
-
-This chapter contains a brief overview of the build process and instructions
-for using the three most commonly used image types. The most versatile image
-type, #{iso-hybrid}#, may be used on a virtual machine, optical media or USB
-portable storage device. In certain special cases, such as the use of
-persistence, #{usb-hdd}# may be more suitable for USB devices. The chapter
-finishes with instructions for building and using a #{net}# type image,
-which is a bit more involved due to the setup required on the server. This
-is a slightly advanced topic for anyone who is not familiar already with
-netbooting, but is included here because once the setup is done, it is a
-very convenient way to test and deploy images for booting on the local
-network without the hassle of dealing with image media.
-
-Throughout the chapter, we will often refer to the default filenames
-produced by live-build. If you are downloading a prebuilt image instead, the
-actual filenames may vary.
-
-2~what-is-live What is a live system?
-
-A live system usually means an operating system booted on a computer from a
-removable medium, such as a CD-ROM or USB stick, or from a network, ready to
-use without any installation on the usual drive(s), with auto-configuration
-done at run time (see {Terms}#terms).
-
-With Debian Live, it's a Debian GNU/Linux operating system, built for one of
-the supported architectures (currently amd64, i386, powerpc and sparc). It
-is made from the following parts:
-
-_* *{Linux kernel image}*, usually named #{vmlinuz*}#
-
-_* *{Initial RAM disk image (initrd)}*: a RAM disk set up for the Linux
-boot, containing modules possibly needed to mount the System image and some
-scripts to do it.
-
-_* *{System image}*: The operating system's filesystem image. Usually, a
-SquashFS compressed filesystem is used to minimize the Debian Live image
-size. Note that it is read-only. So, during boot the Debian Live system will
-use a RAM disk and 'union' mechanism to enable writing files within the
-running system. However, all modifications will be lost upon shutdown unless
-optional persistence is used (see {Persistence}#persistence).
-
-_* *{Bootloader}*: A small piece of code crafted to boot from the chosen
-media, possibly presenting a prompt or menu to allow selection of
-options/configuration. It loads the Linux kernel and its initrd to run with
-an associated system filesystem. Different solutions can be used, depending
-on the target media and format of the filesystem containing the previously
-mentioned components: isolinux to boot from a CD or DVD in ISO9660 format,
-syslinux for HDD or USB drive booting from a VFAT partition, extlinux for
-ext2/3/4 and btrfs partitions, pxelinux for PXE netboot, GRUB for ext2/3/4
-partitions, etc.
-
-You can use live-build to build the system image from your specifications,
-set up a Linux kernel, its initrd, and a bootloader to run them, all in one
-media-dependant format (ISO9660 image, disk image, etc.).
-
-2~building-iso-hybrid First steps: building an ISO hybrid image
-
-Regardless of the image type, you will need to perform the same basic steps
-to build an image each time. As a first example, execute the following
-sequence of live-build commands to create a basic ISO hybrid image
-containing just the Debian standard system without X.org. It is suitable for
-burning to CD or DVD media, and also to copy onto a USB stick.
-
-First, run the #{lb config}# command. This will create a "config/" hierarchy
-in the current directory for use by other commands:
-
-code{
-
- $ lb config
-
-}code
-
-No parameters are passed to #{lb config}#, so defaults for all of its
-various options will be used. See {The lb config command}#lb-config for more
-details.
-
-Now that the "config/" hierarchy exists, build the image with the #{lb
-build}# command:
-
-code{
-
- # lb build
-
-}code
-
-This process can take a while, depending on the speed of your network
-connection. When it is complete, there should be a #{binary-hybrid.iso}#
-image file, ready to use, in the current directory.
-
-2~using-iso-hybrid Using an ISO hybrid live image
-
-After either building or downloading an ISO hybrid image, which can be
-obtained at http://www.debian.org/CD/live/, the usual next step is to
-prepare your media for booting, either CD-R(W) or DVD-R(W) optical media or
-a USB stick.
-
-3~burning-iso-image Burning an ISO image to a physical medium
-
-Burning an ISO image is easy. Just install wodim and use it from the
-command-line to burn the image. For instance:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copying an ISO hybrid image to a USB stick
-
-ISO images prepared with the #{isohybrid}# command, like the images produced
-by the default #{iso-hybrid}# binary image type, can be simply copied to a
-USB stick with the #{dd}# program or an equivalent. Plug in a USB stick with
-a size large enough for your image file and determine which device it is,
-which we hereafter refer to as #{${USBSTICK}}#. This is the device file of
-your key, such as #{/dev/sdb}#, not a partition, such as #{/dev/sdb1}#! You
-can find the right device name by looking in #{dmesg}#'s output after
-plugging in the stick, or better yet, #{ls -l /dev/disk/by-id}#.
-
-Once you are certain you have the correct device name, use the #{dd}#
-command to copy the image to the stick. *{This will definitely overwrite
-any previous contents on your stick!}*
-
-code{
-
- $ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Booting the live media
-
-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.
-
-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.
-
-2~using-virtual-machine Using a virtual machine for testing
-
-It can be a great time-saver for the development of live images to run them
-in a virtual machine (VM). This is not without its caveats:
-
-_* Running a VM requires enough RAM for both the guest OS and the host and a
-CPU with hardware support for virtualization is recommended.
-
-_* There are some inherent limitations to running on a VM, e.g. poor video
-performance, limited choice of emulated hardware.
-
-_* When developing for specific hardware, there is no substitute for running
-on the hardware itself.
-
-_* Occasionally there are bugs that relate only to running in a VM. When in
-doubt, test your image directly on the hardware.
-
-Provided you can work within these constraints, survey the available VM
-software and choose one that is suitable for your needs.
-
-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.
-
-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{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Booting an ISO image is simple:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-See the man pages for more details.
-
-3~testing-iso-with-virtualbox Testing an ISO image with virtualbox-ose
-
-In order to test the ISO with #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Create a new virtual machine, change the storage settings to use
-#{binary-hybrid.iso}# as the CD/DVD device, and start the machine.
-
-Note: For live systems containing X.org that you want to test with
-#{virtualbox-ose}#, you may wish to include the VirtualBox X.org driver
-package, #{virtualbox-ose-guest-x11}#, in your live-build
-configuration. Otherwise, the resolution is limited to 800x600.
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Building a USB/HDD image
-
-Building a USB/HDD image is similar to ISO hybrid in all respects except you
-specify #{-b usb-hdd}# and the resulting filename is #{binary.img}# which
-cannot be burnt to optical media. It is suitable for booting from USB
-sticks, USB hard drives, and various other portable storage
-devices. Normally, an ISO hybrid image can be used for this purpose instead,
-but if you have a BIOS which does not handle hybrid images properly, or want
-to use the remaining space on the media for some purpose, such as a
-persistence partition, you need a USB/HDD image.
-
-Note: if you created an ISO hybrid image with the previous example, you will
-need to clean up your working directory with the #{lb clean}# command (see
-{The lb clean command}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as before, except this time specifying the
-USB/HDD image type:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-When the build finishes, a #{binary.img}# file should be present in the
-current directory.
-
-2~using-usb-hdd-image Using a USB/HDD image
-
-The generated binary image contains a VFAT partition and the syslinux
-bootloader, ready to be directly written on a USB stick. Since using a
-USB/HDD image is just like using an ISO hybrid image on USB, follow the
-instructions in {Using an ISO hybrid live image}#using-iso-hybrid, except
-use the filename #{binary.img}# instead of #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Testing a USB/HDD image with Qemu
-
-First, install QEMU as described above in {Testing an ISO image with
-QEMU}#testing-iso-with-qemu. Then run #{kvm}# or #{qemu}#, depending on
-which version your host system needs, specifying #{binary.img}# as the first
-hard drive.
-
-code{
-
- $ kvm -hda binary.img
-
-}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.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-After the partition is created, where #{${PARTITION}}# is the name of the
-partition, such as #{/dev/sdb2}#, you have to create a filesystem on it. One
-possible choice would be ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Note: If you want to use the extra space with Windows, apparently that OS
-cannot normally access any partitions but the first. Some solutions to this
-problem have been discussed on our {mailing list}#contact, but it seems
-there are no easy answers.
-
-*{Remember: Every time you install a new binary.img on the stick, all data on the stick will be lost because the partition table is overwritten by the contents of the image, so back up your extra partition first to restore again after updating the live image.}*
-
-2~building-netboot-image Building a netboot image
-
-The following sequence of commands will create a basic netboot image
-containing the Debian standard system without X.org. It is suitable for
-booting over the network.
-
-Note: if you performed any previous examples, you will need to clean up your
-working directory with the #{lb clean}# command:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as follows to configure your image for
-netbooting:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-In contrast with the ISO and USB/HDD images, netbooting does not, itself,
-serve the filesystem image to the client, so the files must be served via
-NFS. The #{--net-root-path}# and #{--net-root-server}# options specify the
-location and server, respectively, of the NFS server where the filesytem
-image will be located at boot time. Make sure these are set to suitable
-values for your network and server.
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-In a network boot, the client runs a small piece of software which usually
-resides on the EPROM of the Ethernet card. This program sends a DHCP request
-to get an IP address and information about what to do next. Typically, the
-next step is getting a higher level bootloader via the TFTP protocol. That
-could be pxelinux, GRUB, or even boot directly to an operating system like
-Linux.
-
-For example, if you unpack the generated #{binary-net.tar.gz}# archive in
-the #{/srv/debian-live}# directory, you'll find the filesystem image in
-#{live/filesystem.squashfs}# and the kernel, initrd and pxelinux bootloader
-in #{tftpboot/debian-live/i386}#.
-
-We must now configure three services on the server to enable netboot: the
-DHCP server, the TFTP server and the NFS server.
-
-3~ DHCP server
-
-We must configure our network's DHCP server to be sure to give an IP address
-to the netbooting client system, and to advertise the location of the PXE
-bootloader.
-
-Here is an example for inspiration, written for the ISC DHCP server
-#{isc-dhcp-server}# in the #{/etc/dhcp/dhcpd.conf}# configuration file:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ TFTP server
-
-This serves the kernel and initial ramdisk to the system at run time.
-
-You should install the tftpd-hpa package. It can serve all files contained
-inside a root directory, usually #{/srv/tftp}#. To let it serve files inside
-#{/srv/debian-live/tftpboot}#, run as root the following command:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-and fill in the new tftp server directory when being asked about it.
-
-3~ NFS server
-
-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.
-
-Then, make the filesystem image available through NFS by adding a line like
-the following to #{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-and tell the NFS server about this new export with the following command:
-
-code{
-
- # exportfs -rv
-
-}code
-
-Setting up these three services can be a little tricky. You might need some
-patience to get all of them working together. For more information, see the
-syslinux wiki at http://syslinux.zytor.com/wiki/index.php/PXELINUX or the
-Debian Installer Manual's TFTP Net Booting section at
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. They might help,
-as their processes are very similar.
-
-3~ Netboot testing HowTo
-
-Netboot image creation is made easy with live-build magic, but testing the
-images on physical machines can be really time consuming.
-
-To make our life easier, we can use virtualization. There are two solutions.
-
-3~ Qemu
-
-_* Install #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Edit #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Get, or build a #{grub-floppy-netboot}# (in the svn).
-
-Launch #{qemu}# with "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Install VMWare Player ("free as in beer" edition)
-
-_* Create a PXETester directory, and create a text file called #{pxe.vwx}#
-inside
-
-_* Paste this text inside:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* You can play with this configuration file (e.g. change memory limit to
-256)
-
-_* Double click on this file (or run VMWare player and select this file).
-
-_* When running just press space if that strange question comes up...
diff --git a/manual/de/user_customization-binary.ssi b/manual/de/user_customization-binary.ssi
deleted file mode 100644
index 6f843f8..0000000
--- a/manual/de/user_customization-binary.ssi
+++ /dev/null
@@ -1,35 +0,0 @@
-B~ Customizing the binary image
-
-1~customizing-binary Customizing the binary image
-
-2~ Bootloader
-
-live-build uses syslinux as bootloader by default, which is by default
-configured to pause indefinitely at its splash screen. To adjust this, you
-can pass #{--syslinux-timeout TIMEOUT}# to #{lb config}#. The value is
-specified in units of seconds. A timeout of 0 (zero) disables the timeout
-completely. For more information please see syslinux(1).
-
-2~ ISO metadata
-
-When creating an ISO9660 binary image, you can use the following options to
-add various textual metadata for your image. This can help you easily
-identify the version or configuration of an image without booting it.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: This should describe the
-application that will be on the image. The maximum length for this field is
-128 characters.
-
-_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: This should describe the
-preparer of the image, usually with some contact details. The default for
-this option is the live-build version you are using, which may help with
-debugging later. The maximum length for this field is 128 characters.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: This should describe the
-publisher of the image, usually with some contact details. The maximum
-length for this field is 128 characters.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: This should specify the volume ID of
-the image. This is used as a user-visible label on some platforms such as
-Windows and Apple Mac OS. The maximum length for this field is 32
-characters.
diff --git a/manual/de/user_customization-contents.ssi b/manual/de/user_customization-contents.ssi
deleted file mode 100644
index 814ba40..0000000
--- a/manual/de/user_customization-contents.ssi
+++ /dev/null
@@ -1,154 +0,0 @@
-:B~ Customizing contents
-
-1~customizing-contents Customizing contents
-
-This chapter discusses fine-tuning customization of the live system contents
-beyond merely choosing which packages to include. Includes allow you to add
-or replace arbitrary files in your Debian Live image, hooks allow you to
-execute arbitrary commands at different stages of the build and at boot
-time, and preseeding allows you to configure packages when they are
-installed by supplying answers to debconf questions.
-
-2~ Includes
-
-While ideally a Debian live system would include files entirely provided by
-unmodified Debian packages, it is sometimes convenient to provide or modify
-some content by means of files. Using includes, it is possible to add (or
-replace) arbitrary files in your Debian Live image. live-build provides
-three mechanisms for using them:
-
-_* Chroot local includes: These allow you to add or replace files to the
-chroot/Live filesystem. Please see {Live/chroot local
-includes}#live-chroot-local-includes for more information.
-
-_* Binary local includes: These allow you to add or replace files in the
-binary image. Please see {Binary local includes}#binary-local-includes for
-more information.
-
-_* Binary includes: These allow you to add or replace Debian specific files
-in the binary image, such as the templates and tools directories. Please see
-{Binary includes}#binary-includes for more information.
-
-Please see {Terms}#terms for more information about the distinction between
-the "Live" and "binary" images.
-
-3~live-chroot-local-includes Live/chroot local includes
-
-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/chroot_local-includes}#
-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{
-
- $ mkdir -p config/chroot_local-includes/var/www
- $ cp /path/to/my/index.html config/chroot_local-includes/var/www
-
-}code
-
-Your configuration will then have the following layout:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Chroot local includes are installed after package installation so that files
-installed by packages are overwritten.
-
-3~binary-local-includes Binary local includes
-
-To include material such as documentation or videos on the media filesystem
-so that it is accessible immediately upon insertion of the media without
-booting the Live system, you can use binary local includes. This works in a
-similar fashion to chroot local includes. For example, suppose the files
-#{~/video_demo.*}# are demo videos of the live system described by and
-linked to by an HTML index page. Simply copy the material to
-#{config/binary_local-includes/}# as follows:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-These files will now appear in the root directory of the live media.
-
-3~binary-includes Binary includes
-
-live-build has some standard files (like documentation) that gets included
-in the default configuration on every live media. This can be disabled with:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-Otherwise, the material will be installed by live-build in #{/includes/}# by
-default on the media filesystem, or else you can specify an alternate path
-with #{--includes}#.
-
-2~ Hooks
-
-Hooks allow commands to be performed in the chroot and binary stages of the
-build in order to customize the image.
-
-3~live-chroot-local-hooks Live/chroot local hooks
-
-To run commands in the chroot stage, create a hook script containing the
-commands in the #{config/chroot_local-hooks}# directory. The hook will run
-in the chroot after the rest of your chroot configuration has been applied,
-so remember to ensure your configuration includes all packages and files
-your hook needs in order to run. See the example chroot hook scripts for
-various common chroot customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-3~boot-time-hooks Boot-time hooks
-
-To execute commands at boot time, you can supply live-config hooks as
-explained in the "Customization" section of its man page. Examine
-live-config's own hooks provided in #{/lib/live/config/}#, noting the
-sequence numbers. Then provide your own hook prefixed with an appropriate
-sequence number, either as a chroot local include in
-#{config/chroot_local-includes/lib/live/config/}#, or as a custom package as
-discussed in {Installing modified or third-party
-packages}#installing-modified-or-third-party-packages.
-
-3~ Binary local hooks
-
-To run commands in the binary stage, create a hook script containing the
-commands in the #{config/binary_local-hooks}#. The hook will run after all
-other binary commands are run, but before binary_checksums, the very last
-binary commands The commands in your hook do not run in the chroot, so take
-care to not modify any files outside of the build tree, or you may damage
-your build system! See the example binary hook scripts for various common
-binary customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-2~ Preseeding Debconf questions
-
-Files in the #{config/chroot_local-preseed}# directory are considered to be
-debconf preseed files and are installed by live-build using
-#{debconf-set-selections}#.
-
-For more information about debconf, please see debconf(7) in the #{debconf}#
-package.
diff --git a/manual/de/user_customization-installer.ssi b/manual/de/user_customization-installer.ssi
deleted file mode 100644
index 9349f27..0000000
--- a/manual/de/user_customization-installer.ssi
+++ /dev/null
@@ -1,88 +0,0 @@
-:B~ Customizing Debian Installer
-
-1~customizing-installer Customizing Debian Installer
-
-Debian Live system images can be integrated with Debian Installer. There are
-a number of different types of installation, varying in what is included and
-how the installer operates.
-
-Please note the careful use of capital letters when referring to the "Debian
-Installer" in this section - when used like this we refer explicitly to the
-official installer for the Debian system, not anything else. It is often
-seen abbreviated to "d-i".
-
-2~ Types of Debian Installer
-
-The three main types of installer are:
-
-*{"Regular" Debian Installer}*: This is a normal Debian Live image with a seperate kernel and initrd which (when selected from the appropriate bootloader) launches into a standard Debian Installer instance, just as if you had downloaded a CD image of Debian and booted it. Images containing a live system and such an otherwise independent installer are often referred to as "combined images".
-
-On such images, Debian is installed by fetching and installing .deb packages
-using #{debootstrap}# or #{cdebootstrap}#, from the local media or some
-network-based network, resulting in a standard Debian system being installed
-to the hard disk.
-
-This whole process can be preseeded and customized in a number of ways; see
-the relevant pages in the Debian Installer manual for more information. Once
-you have a working preseeding file, live-build can automatically put it in
-the image and enable it for you.
-
-*{"Live" Debian Installer}*: This is a Debian Live image with a separate kernel and initrd which (when selected from the appropriate bootloader) launches into an instance of the Debian Installer.
-
-Installation will proceed in an identical fashion to the "Regular"
-installation described above, but at the actual package installation stage,
-instead of using #{debootstrap}# to fetch and install packages, the live
-filesystem image is copied to the target. This is achieved with a special
-udeb called live-installer.
-
-After this stage, the Debian Installer continues as normal, installing and
-configuring items such as bootloaders and local users, etc.
-
-Note: to support both normal and live installer entries in the bootloader of
-the same live media, you must disable live-installer by preseeding
-#{live-installer/enable=false}#.
-
-*{"Desktop" Debian Installer}*: Regardless of the type of Debian Installer included, #{d-i}# can be launched from the Desktop by clicking on an icon. This is user friendlier in some situations. In order to make use of this, the debian-installer-launcher package needs to be included.
-
-Note that by default, live-build does not include Debian Installer images in
-the images, it needs to be specifically enabled with #{lb config}#. Also,
-please note that for the "Desktop" installer to work, the kernel of the live
-system must match the kernel #{d-i}# uses for the specified
-architecture. For example:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Customizing Debian Installer by preseeding
-
-As described in the Debian Installer Manual, Appendix B at
-http://www.debian.org/releases/stable/i386/apb.html, "Preseeding provides a
-way to set answers to questions asked during the installation process,
-without having to manually enter the answers while the installation is
-running. This makes it possible to fully automate most types of installation
-and even offers some features not available during normal installations."
-This kind of customization is best accomplished with live-build by placing
-the configuration in a #{preseed.cfg}# file included in
-#{config/binary_debian-installer/}#. For example, to preseed setting the
-locale to #{en_US}#:
-
-code{
-
- $ echo "d-i debian-installer/locale string en_US" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Customizing Debian Installer content
-
-For experimental or debugging purposes, you might want to include locally
-built #{d-i}# component udeb packages. Place these in
-#{config/binary_local-udebs/}# to include them in the image. Additional or
-replacement files and directories may be included in the installer initrd as
-well, in a similar fashion to {Live/chroot local
-includes}#live-chroot-local-includes, by placing the material in
-#{config/binary_debian-installer-includes/}#.
diff --git a/manual/de/user_customization-overview.ssi b/manual/de/user_customization-overview.ssi
deleted file mode 100644
index 137e322..0000000
--- a/manual/de/user_customization-overview.ssi
+++ /dev/null
@@ -1,76 +0,0 @@
-:B~ Customizing contents
-
-1~customization-overview Customization overview
-
-This chapter gives an overview of the various ways in which you may
-customize a Debian Live system.
-
-2~ Build time vs. boot time configuration
-
-Live system configuration options are divided into build-time options which
-are options that are applied at build time and boot-time options which are
-applied at boot time. Boot-time options are further divided into those
-occurring early in the boot, applied by the live-boot package, and those
-that happen later in the boot, applied by live-config. Any boot-time option
-may be modified by the user by specifying it at the boot prompt. The image
-may also be built with default boot parameters so users can normally just
-boot directly to the live system without specifying any options when all of
-the defaults are suitable. In particular, the argument to #{lb
---bootappend-live}# consists of any default kernel command line options for
-the Live system, such as persistence, keyboard layouts, or timezone. See
-{Customizing locale and language}#customizing-locale-and-language, for
-example.
-
-Build-time configuration options are described in the #{lb config}# man
-page. Boot-time options are described in the man pages for live-boot and
-live-config. Although the live-boot and live-config packages are installed
-within the live system you are building, it is recommended that you also
-install them on your build system for easy reference when you are working on
-your configuration. It is safe to do so, as none of the scripts contained
-within them are executed unless the system is configured as a live system.
-
-2~stages-of-the-build Stages of the build
-
-The build process is divided into stages, with various customizations
-applied in sequence in each. The first stage to run is the *{bootstrap}*
-stage. This is the initial phase of populating the chroot directory with
-packages to make a barebones Debian system. This is followed by the
-*{chroot}* stage, which completes the construction of chroot directory,
-populating it with all of the packages listed in the configuration, along
-with any other materials. Most customization of content occurs in this
-stage. The final stage of preparing the live image is the *{binary}* stage,
-which builds a bootable image, using the contents of the chroot directory to
-construct the root filesystem for the Live system, and including the
-installer and any other additional material on the target media outside of
-the Live system's filesystem. After the live image is built, if enabled, the
-source tarball is built in the *{source}* stage.
-
-Within each of these stages, there is a particular sequence in which
-commands are applied. These are arranged in such a way as to ensure
-customizations can be layered in a reasonable fashion. For example, within
-the *{chroot}* stage, preseeds are applied before any packages are
-installed, packages are installed before any locally included files or
-patches are applied, and hooks are run later, after all of the materials are
-in place.
-
-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.
-
-2~ Customization tasks
-
-The following chapters are organized by the kinds of customization task
-users typically perform: {Customizing package
-installation}#customizing-package-installation, {Customizing
-contents}#customizing-contents and {Customizing locale and
-language}#customizing-locale-and-language cover just a few of the things you
-might want to do.
diff --git a/manual/de/user_customization-packages.ssi b/manual/de/user_customization-packages.ssi
deleted file mode 100644
index 6b6f4fa..0000000
--- a/manual/de/user_customization-packages.ssi
+++ /dev/null
@@ -1,586 +0,0 @@
-:B~ Customizing package installation
-
-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.
-
-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 #{squeeze}# for the Squeeze 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{
-
- $ lb config --distribution sid
-
-}code
-
-Within the distribution archive, archive areas are major divisions of the
-archive. In Debian, these are #{main}#, #{contrib}# and #{non-free}#. Only
-#{main}# contains software that is part of the Debian distribution, hence
-that is the default. One or more values may be specified, e.g.
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Experimental support is available for some Debian derivatives through a
-#{--mode}# option. By default, this option is set to #{debian}#, even if you
-are building on a non-Debian system. If you specify #{--mode ubuntu}# or
-#{--mode emdebian}#, the distribution names and archive areas for the
-specified derivative are supported instead of the ones for Debian. The mode
-also modifies live-build behaviour to suit the derivatives.
-
-*{Note:}* The projects for whom these modes were added are primarily responsible for supporting users of these options. The Debian live project, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
-
-3~ Distribution mirrors
-
-The Debian archive is replicated across a large network of mirrors around
-the world so that people in each region can choose a nearby mirror for best
-download speed. Each of the #{--mirror-*}# options governs which
-distribution mirror is used at various stages of the build. Recall from
-{Stages of the build}#stages-of-the-build that the *bootstrap* stage is when
-the chroot is initially populated by debootstrap with a minimal system, and
-the *chroot* stage is when the chroot used to construct the live system's
-filesystem is built. Thus, the corresponding mirror switches are used for
-those stages, and later, in the *binary* stage, the #{--mirror-binary}# and
-#{--mirror-binary-security}# values are used, superceding any mirrors used
-in an earlier stage.
-
-3~distribution-mirrors-build-time Distribution mirrors used at build time
-
-To set the distribution mirrors used at build time to point at a local
-mirror, it is sufficient to set #{--mirror-bootstrap}# and
-#{--mirror-chroot-security}# as follows.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-The chroot mirror, specified by #{--mirror-chroot}#, defaults to the
-#{--mirror-bootstrap}# value.
-
-3~ Distribution mirrors used at run time
-
-The #{--mirror-binary*}# options govern the distribution mirrors placed in
-the binary image. These may be used to install additional packages while
-running the live system. The defaults employ #{cdn.debian.net}#, a service
-that chooses a geographically close mirror based on the user's IP
-number. This is a suitable choice when you cannot predict which mirror will
-be best for all of your users. Or you may specify your own values as shown
-in the example below. An image built from this configuration would only be
-suitable for users on a network where "#{mirror}#" is reachable.
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Additional repositories
-
-You may add more repositories, broadening your package choices beyond what
-is available in your target distribution. These may be, for example, for
-backports, experimental or custom packages. To configure additional
-repositories, create #{config/chroot_sources/your-repository.chroot}#,
-and/or #{config/chroot_sources/your-repository.binary}# files. As with the
-#{--mirror-*}# options, these govern the repositories used in the *chroot*
-stage when building the image, and in the *binary* stage, i.e. for use when
-running the live system.
-
-For example, #{config/chroot_sources/live.chroot}# allows you to install
-packages from the debian live snapshot repository at live system build time.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-If you add the same line to #{config/chroot_sources/live.binary}#, the
-repository will be added to your live system's #{/etc/apt/sources.list.d/}#
-directory.
-
-If such files exist, they will be picked up automatically.
-
-You should also put the GPG key used to sign the repository into
-#{config/chroot_sources/your-repository.{binary,chroot}.gpg}# files.
-
-*{Note:}* some preconfigured package repositories are available for easy selection through the #{--repository}# option, e.g. for enabling live snapshots, a simple command is enough to enable it:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Choosing packages to install
-
-There are a number of ways to choose which packages live-build will install
-in your image, covering a variety of different needs. You can simply name
-individual packages to install, either with the #{--packages}# option for a
-few packages, or in a package list of your own for larger numbers. You can
-also choose larger predefined lists of packages, or use APT tasks. And
-finally, you may place package files in your #{config/}# tree, which is well
-suited to testing of new or experimental packages before they are available
-from a repository.
-
-3~ Choosing a few packages
-
-When the number of packages added is small, simply specify
-#{--packages}#. For example:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-The behaviour of live-build when specifying a package that does not exist is
-determined by your choice of APT utility. See {Choosing apt or
-aptitude}#choosing-apt-or-aptitude for more details.
-
-If you need to specify a large number of packages to be installed or you
-need flexibility regarding which packages to install, use package lists as
-discussed in the following section, {Package lists}#package-lists.
-
-3~package-lists Package lists
-
-Package lists are a powerful way of expressing which packages should be
-installed. The list syntax supports included files and conditional sections
-which makes it easy to build lists from other lists and adapt them for use
-in multiple configurations. You can use predefined package lists, providing
-in a modular fashion package selections from each of the major desktop
-environments and some special purpose lists, as well as standard lists the
-others are based upon. You can also provide your own package lists, or use a
-combination of both.
-
-3~ Predefined package lists
-
-The simplest way to use lists is to specify one or more predefined lists
-with the #{--packages-lists}# option. For example:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-In addition to these lists, live-build supports four virtual package lists:
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#,
-each of which provide a more extensive selection of packages that
-corresponds with Debian Installer defaults for these desktop
-environments. See {Desktop and language tasks}#desktop-and-language-tasks
-for more details.
-
-*{Note:}* The prebuilt GNOME, KDE, LXDE and XFCE images available for download at http://live.debian.net are built using the corresponding virtual #{*-desktop}# lists.
-
-The default location for the list files on your system is
-#{/usr/share/live/build/lists/}#. To determine the packages in a given list,
-read the corresponding file, paying attention to included files and
-conditionals as described in the following sections.
-
-3~ Local package lists
-
-You may supplement or replace entirely the supplied lists using local
-package lists stored in #{config/chroot_local-packageslists/}#.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed. Local package lists always override package lists
-distributed with live-build. This can cause undesired effects, we therefore
-recommend to use unique names for local package lists.
-
-3~ Local binary package lists
-
-In case you want to include some required .deb packages to live media's
-#{pool/}# (without installing them onto the live image) you may need to use
-lists using binary local package lists stored in
-#{config/binary_local-packageslists/}#. Such media can be used as a
-customized Debian install image for offline installations.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed.
-
-3~ Extending a provided package list using includes
-
-The package lists that are included with live-build make extensive use of
-includes. Refer to these in the #{/usr/share/live/build/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/chroot_local-packageslists/mygnome.list}# with
-the following contents:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Using conditionals inside package lists
-
-Any of the live-build configuration variables stored in #{config/*}# (minus
-the #{LB_}# prefix) may be used in conditional statements in package
-lists. Generally, this means any #{lb config}# option uppercased and with
-dashes changed to underscores. But in practice, it is only the ones that
-influence package selection that make sense, such as #{DISTRIBUTION}#,
-#{ARCHITECTURE}# or #{ARCHIVE_AREAS}#.
-
-For example, to install #{ia32-libs}# if the #{--architecture amd64}# is
-specified:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-You may test for any one of a number of values, e.g. to install
-#{memtest86+}# if either #{--architecture i386}# or #{--architecture amd64}#
-is specified:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-You may also test against variables that may contain more than one value,
-e.g. to install #{vrms}# if either #{contrib}# or #{non-free}# is specified
-via #{--archive-areas}#:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-A conditional may surround an #{#include}# directive:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-The nesting of conditionals is not supported.
-
-3~ Tasks
-
-The Debian Installer offers the user choices of a number of preselected
-lists of packages, each one focused on a particular kind of system, or task
-a system may be used for, such as "Graphical desktop environment", "Mail
-server" or "Laptop". These lists are called "tasks" and are supported by APT
-through the "Task:" field. You can specify one or more tasks in live-build
-via the #{--tasks}# option, as in the example below.
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-The primary tasks available in the Debian Installer can be listed with
-#{tasksel --list-tasks}# in the live system. The contents of any task,
-including ones not included in this list, may be examined with #{tasksel
---task-packages}#.
-
-3~desktop-and-language-tasks Desktop and language tasks
-
-Desktop and language tasks are special cases. In the Debian Installer, if
-the medium was prepared for a particular desktop environment flavour, the
-corresponding task will be automatically installed. Thus, there are
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#
-tasks, none of which are offered in #{tasksel}#'s menu. Likewise, there are
-no menu entries for tasks for languages, but the user's language choice
-during the install influences the selection of corresponding language tasks.
-
-In live-build, therefore, these special cases are also given special
-consideration, but with three notable differences at the time of writing.
-
-First, there is no provision made yet automatically for language tasks,
-although a subset of those packages are included if you specify #{lb config
---language}#. If you need those tasks, which include such things as
-language-specific fonts and input-method packages, you need to specify them
-in your configuration. For example:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-Second, live-build supports #{*-desktop}# virtual package lists for each of
-the desktop flavours mentioned above, which select the #{standard-x11}#
-predefined package list, the corresponding #{*-desktop}# task and three
-additional tasks: #{desktop}#, #{standard}# and #{laptop}#. So, for example,
-if you specify #{--packages-lists gnome-desktop}#, it is equivalent to
-specifying #{--packages debian-installer-launcher --packages-lists
-standard-x11 --tasks "gnome-desktop desktop standard laptop"}#.
-
-Third, if any of the tasks for these desktop flavours are selected, either
-explicitly through #{--tasks}# or implicitly by #{--packages-lists}#,
-live-build will preseed the corresponding desktop value for Debian Installer
-(if it is included) to ensure it follows its own rules for installing
-different desktop flavours.
-
-*{Note:}* There is also an experimental #{--language}# option that has an overlapping purpose with language tasks. For any language for which it is known that there are #{*-l10n}# packages, if #{--language}# is specified, those packages will be installed. Furthermore, if any #{syslinux}# templates matching the language are found, they will be used instead of the default English templates. The package selection done by #{--language}# is a poor approximation of language tasks, as it requires that the list of packages to include per language be maintained internally in live-build, and besides, language tasks are more comprehensive and flexible. However, the #{syslinux}# aspect is still useful. Thus, if you use #{--bootloader syslinux}# and templates for the specified language exist either in #{/usr/share/live/build/templates/syslinux/}# or #{config/templates/syslinux/}#, consider using this option, possibly in combination with tasks to ensure all relevant packages are installed
. For example:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Even so, it is limited in that it only supports a single language and a
-single bootloader. Therefore, for all of these reasons, the future of this
-option is under review, possibly to be replaced with something entirely
-different in the next major release of live-build.
-
-2~installing-modified-or-third-party-packages Installing modified or
-third-party packages
-
-Whilst it is against the philosophy of Debian Live, it may sometimes be
-necessary to build a Live system with modified versions of packages that are
-in the Debian repository. This may be to modify or support additional
-features, languages and branding, or even to remove elements of existing
-packages that are undesirable. Similarly, "third-party" packages may be used
-to add bespoke and/or proprietary functionality.
-
-This section does not cover advice regarding building or maintaining
-modified packages. Joachim Breitner's 'How to fork privately' method from
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
-may be of interest, however. The creation of bespoke packages is covered in
-the Debian New Maintainers' Guide at http://www.debian.org/doc/maint-guide/
-and elsewhere.
-
-There are two ways of installing modified custom packages:
-
-_* #{chroot_local-packages}#
-
-_* Using a custom APT repository
-
-Using #{chroot_local-packages}# is simpler to achieve and useful for
-"one-off" customizations but has a number of drawbacks, whilst using a
-custom APT repository is more time-consuming to set up.
-
-3~ Using #{chroot_local-packages}# to install custom packages
-
-To install a custom package, simply copy it to the
-#{config/chroot_local-packages/}# directory. Packages that are inside this
-directory will be automatically installed into the live system during build
-- you do not need to specify them elsewhere.
-
-Packages *{must}* be named in the prescribed way. One simple way to do this
-is to use #{dpkg-name}#.
-
-Using #{chroot_local-packages}# for installation of custom packages has
-disadvantages:
-
-_* It is not possible to use secure APT.
-
-_* You must install all appropriate packages in the
-#{config/chroot_local-packages/}# directory.
-
-_* It does not lend itself to storing Debian Live configurations in revision
-control.
-
-3~ Using an APT repository to install custom packages
-
-Unlike using #{chroot_local-packages}#, when using a custom APT repository
-you must ensure that you specify the packages elsewhere. See {Choosing
-packages to install}#choosing-packages-to-install for details.
-
-Whilst it may seem unnecessary effort to create an APT repository to install
-custom packages, the infrastructure can be easily re-used at a later date to
-offer updates of the modified packages.
-
-3~ Custom packages and APT
-
-live-build uses APT to install all packages into the live system so will
-therefore inherit behaviours from this program. One relevant example is that
-(assuming a default configuration) given a package available in two
-different repositories with different version numbers, APT will elect to
-install the package with the higher version number.
-
-Because of this, you may wish to increment the version number in your custom
-packages' #{debian/changelog}# files to ensure that your modified version is
-installed over one in the official Debian repositories. This may also be
-achieved by altering the live system's APT pinning preferences - see {APT
-pinning}#apt-pinning for more information.
-
-2~ Configuring APT at build time
-
-You can configure APT through a number of options applied only at build
-time. (APT configuration used in the running live system may be configured
-in the normal way for live system contents, that is, by including the
-appropriate configurations through #{config/chroot_local_includes/}#.) For a
-complete list, look for options starting with #{apt}# in the #{lb_config}#
-man page.
-
-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.
-
-_* #{apt}#: With this method, if a missing package is specified, the package
-installation will fail. This is the default setting.
-
-_* #{aptitude}#: With this method, if a missing package is specified, the
-package installation will succeed.
-
-3~ Using a proxy with APT
-
-One commonly required APT configuration is to deal with building an image
-behind a proxy. You may specify your APT proxy with the #{--apt-ftp-proxy}#
-or #{--apt-http-proxy}# options as needed, e.g.
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Tweaking APT to save space
-
-You may find yourself needing to save some space on the image media, in
-which case one or the other or both of the following options may be of
-interest.
-
-If you don't want to include APT indices in the image, you can omit those
-with:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-This will not influence the entries in /etc/apt/sources.list, but merely
-whether /var/lib/apt contains the indices files or not. The tradeoff is that
-APT needs those indices in order to operate in the live system, so before
-performing #{apt-cache search}# or #{apt-get install}#, for instance, the
-user must #{apt-get update}# first to create those indices.
-
-If you find the installation of recommended packages bloats your image too
-much, you may disable that default option of APT with:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-The tradeoff here is that if you don't install recommended packages for a
-given package, that is, "packages that would be found together with this one
-in all but unusual installations" (Debian Policy Manual, section 7.2), some
-packages that you actually need may be omitted. Therefore, we suggest you
-review the difference turning off recommends makes to your packages list
-(see the #{binary.packages}# file generated by #{lb build}#) and re-include
-in your list any missing packages that you still want
-installed. Alternatively, if you find you only want a small number of
-recommended packages left out, leave recommends enabled and set a negative
-APT pin priority on selected packages to prevent them from being installed,
-as explained in {APT pinning}#apt-pinning.
-
-3~ Passing options to apt or aptitude
-
-If there is not an #{lb config}# option to alter APT's behaviour in the way
-you need, use #{--apt-options}# or #{--aptitude-options}# to pass any
-options through to your configured APT tool. See the man pages for #{apt}#
-and #{aptitude}# for details.
-
-3~apt-pinning APT pinning
-
-For background, please first read the #{apt_preferences(5)}# man page. APT
-pinning can be configured either for build time, or else for run time. For
-the former, create #{config/chroot_apt/preferences}#. For the latter, create
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Let's say you are building a Squeeze live system but need all the live
-packages that end up in the binary image to be installed from Sid at build
-time. You need to add Sid to your APT sources and pin it so that only the
-packages you want are installed from it at build time and all others are
-taken from the target system distribution, Squeeze. The following will
-accomplish this:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Note:}* Wildcards can be used in package names (e.g. *{Package: live-*}*) with Apt version 0.8.14 or higher. This means that it works with Wheezy using:
-
-code{
-
-$ 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 #{--packages-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{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/de/user_customization-runtime.ssi b/manual/de/user_customization-runtime.ssi
deleted file mode 100644
index 4bbf347..0000000
--- a/manual/de/user_customization-runtime.ssi
+++ /dev/null
@@ -1,229 +0,0 @@
-:B~ Customizing run time behaviours
-
-1~customizing-run-time-behaviours Customizing run time behaviours
-
-All configuration that is done during run time is done by live-config. Here
-are some of the most common options of live-config that users are interested
-in. A full list of all possibilities can be found in the manpage of
-live-config.
-
-2~ Customizing the live user
-
-One important consideration is that the live user is created by live-boot at
-boot time, not by live-build at build time. This not only influences where
-materials relating to the live user are introduced in your build, as
-discussed in {Live/chroot local includes}#live-chroot-local-includes, but
-also any groups and permissions associated with the live user.
-
-You can specify additional groups that the live user will belong to by
-preseeding the #{passwd/user-default-groups}# debconf value. For example, to
-add the live user to the #{fuse}# group, add the following to a file in the
-#{config/chroot_local-preseed}# directory:
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-It is also possible to change the default username "user" and the default
-password "live". If you want to do that for any reason, you can easily
-achieve it as follows:
-
-To change the default username you can simply specify it in your config:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-One possible way of changing the default password is by means of a hook as
-described in {Boot-time hooks}#boot-time-hooks. In order to do that you can
-use the "passwd" hook from #{/usr/share/doc/live-config/examples/hooks}#,
-prefix it accordingly (e.g. 200-passwd) and add it to
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Customizing locale and language
-
-When the live system boots, language is involved in three steps:
-
-_* the locale generation
-
-_* setting the keyboard layout for the console
-
-_* setting the keyboard layout for X
-
-The default locale when building a Live system is "locales=en_US.UTF-8". To
-define the locale that should be generated, use the #{locales}# parameter in
-the #{--bootappend-live}# option of #{lb config}#, e.g.
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-This parameter can also be used at the kernel command line. You can specify
-a locale by a full #{language_country.encoding}# word.
-
-Both the console and X keyboard configuration depend on the
-#{keyboard-layouts}# parameter of the #{--bootappend-live}# option. Valid
-options for X keyboard layouts can be found in
-#{/usr/share/X11/xkb/rules/base.xml}# (rather limited to two-letters country
-codes). To find the value (the two characters) corresponding to a language
-try searching for the english name of the nation where the language is
-spoken, e.g:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-To get the locale files for German and Swiss German keyboard layout in X
-use:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-A list of the valid values of the keyboards for the console can be figured
-with the following command:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-Alternatively, you can use the #{console-setup}# package, a tool to let you
-configure console layout using X (XKB) definitions; you can then set your
-keyboard layout more precisely with #{keyboard-layouts}#,
-#{keyboard-variant}#, #{keyboard-options}# and #{keyboard-model}# variables;
-live-boot will use also these parameters for X configuration. For example,
-to set up a French system with a French-Dvorak layout (called Bepo) on a
-TypeMatrix keyboard, both in console and X11, use:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistence
-
-A live cd paradigm is a pre-installed system which runs from read-only
-media, like a cdrom, where writes and modifications do not survive reboots
-of the host hardware which runs it.
-
-A Debian Live system is a generalization of this paradigm and thus supports
-other media in addition to CDs; but still, in its default behaviour, it
-should be considered read-only and all the run-time evolutions of the system
-are lost at shutdown.
-
-Persistence is a common name for different kinds of solutions for saving
-across reboots some, or all, of this run-time evolution of the system. To
-understand how it could work it could be handy to know that even if the
-system is booted and run from read-only media, modification to the files and
-directories are written on writable media, typically a ram disk (tmpfs) and
-ram disks' data do not survive reboots.
-
-The data stored on this ramdisk should be saved on a writable persistent
-medium like a Hard Disk, a USB key, a network share or even a session of a
-multisession (re)writable CD/DVD. All these media are supported in Debian
-Live in different ways, and all but the last one require a special boot
-parameter to be specified at boot time: #{persistent}#.
-
-3~ Full persistence
-
-By 'full persistence' it is meant that instead of using a tmpfs for storing
-modifications to the read-only media (with the copy-on-write, COW, system) a
-writable partition is used. In order to use this feature a partition with a
-clean writable supported filesystem on it labeled "live-rw" must be attached
-on the system at boot time and the system must be started with the boot
-parameter 'persistent'. This partition could be an ext2 partition on the
-hard disk or on a usb key created with, e.g.:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-See also {Using the space left on a USB stick}#using-usb-extra-space.
-
-If you already have a partition on your device, you could just change the
-label with one of the following:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-But since live system users cannot always use a hard drive partition, and
-considering that most USB keys have poor write speeds, 'full' persistence
-could be also used with just image files, so you could create a file
-representing a partition and put this image file even on a NTFS partition of
-a foreign OS, with something like:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-Then copy the #{live-rw}# file to a writable partition and reboot with the
-boot parameter 'persistent'.
-
-3~ Home automounting
-
-If during the boot a partition (filesystem) image file or a partition
-labeled #{home-rw}# is discovered, this filesystem will be directly mounted
-as #{/home}#, thus permitting persistence of files that belong to e.g. the
-default user. It can be combined with full persistence.
-
-3~ Snapshots
-
-Snapshots are collections of files and directories which are not mounted
-while running but which are copied from a persistent device to the system
-(tmpfs) at boot and which are resynced at reboot/shutdown of the system. The
-content of a snapshot could reside on a partition or an image file (like the
-above mentioned types) labeled #{live-sn}#, but it defaults to a simple cpio
-archive named #{live-sn.cpio.gz}#. As above, at boot time, the block devices
-connected to the system are traversed to see if a partition or a file named
-like that could be found. A power interruption during run time could lead to
-data loss, hence a tool invoked #{live-snapshot --refresh}# could be called
-to sync important changes. This type of persistence, since it does not write
-continuously to the persistent media, is the most flash-based device
-friendly and the fastest of all the persistence systems.
-
-A /home version of snapshot exists too and its label is #{home-sn.*}#; it
-works the same as the main snapshot but it is only applied to /home.
-
-Snapshots cannot currently handle file deletion but full persistence and
-home automounting can.
-
-3~ Persistent SubText
-
-If a user would need multiple persistent storage of the same type for
-different locations or testing, such as #{live-rw-nonwork}# and
-#{live-rw-work}#, the boot parameter #{persistent-subtext}# used in
-conjunction with the boot parameter #{persistent}# will allow for multiple
-but unique persistent media. An example would be if a user wanted to use a
-persistent partition labeled #{live-sn-subText}# they would use the boot
-parameters of: #{persistent}# #{persistent-subtext=subText}#.
-
-3~ Partial remastering
-
-The run-time modification of the tmpfs could be collected using
-live-snapshot in a squashfs and added to the cd by remastering the iso in
-the case of cd-r or adding a session to multisession cd/dvd(rw); live-boot
-mounts all /live filesystem in order or with the module boot parameter.
diff --git a/manual/de/user_examples.ssi b/manual/de/user_examples.ssi
deleted file mode 100644
index 5bb918a..0000000
--- a/manual/de/user_examples.ssi
+++ /dev/null
@@ -1,395 +0,0 @@
-:B~ Examples
-
-1~examples Examples
-
-This chapter covers example builds for specific use cases with Debian
-Live. If you are new to building your own Debian Live images, we recommend
-you first look at the three tutorials in sequence, as each one teaches new
-techniques that will help you use and understand the remaining examples.
-
-2~using-the-examples Using the examples
-
-To use these examples you need a system to build them on that meets the
-requirements listed in {Requirements}#requirements and has live-build
-installed as described in {Installing live-build}#installing-live-build.
-
-Note that, for the sake of brevity, in these examples we do not specify a
-local mirror to use for the build. You can speed up downloads considerably
-if you use a local mirror. You may specify the options when you use #{lb
-config}#, as described in {Distribution mirrors used at build
-time}#distribution-mirrors-build-time, or for more convenience, set the
-default for your build system in #{/etc/live/build.conf}#. Simply create
-this file and in it, set the corresponding #{LB_MIRROR_*}# variables to your
-preferred mirror. For example:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: A standard image
-
-*{Use case:}* Create a simple first image, learning the basics of live-build.
-
-In this tutorial, we will build a default ISO hybrid Debian Live image
-containing only base packages (no Xorg) and some Debian Live support
-packages, as a first exercise in using live-build.
-
-You can't get much simpler than this:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Examine the contents of the #{config/}# directory if you wish. You will see
-stored here a skeletal configuration, ready to customize or, in this case,
-use immediately to build a default image.
-
-Now, as superuser, build the image, saving a log as you build with #{tee}#.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Assuming all goes well, after a while, the current directory will contain
-#{binary-hybrid.iso}#. This ISO hybrid image can be booted directly in a
-virtual machine as described in {Testing an ISO image with
-Qemu}#testing-iso-with-qemu and {Testing an ISO image with
-virtualbox-ose}#testing-iso-with-virtualbox, or else imaged onto optical
-media or a USB flash device as described in {Burning an ISO image to a
-physical medium}#burning-iso-image and {Copying an ISO hybrid image to a USB
-stick}#copying-iso-hybrid-to-usb, respectively.
-
-2~tutorial-2 Tutorial 2: A web browser utility
-
-*{Use case:}* Create a web browser utility image, learning how to apply customizations.
-
-In this tutorial, we will create an image suitable for use as a web browser
-utility, serving as an introduction to customizing Debian Live images.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-Our choice of LXDE for this example reflects our desire to provide a minimal
-desktop environment, since the focus of the image is the single use we have
-in mind, the web browser. We could go even further and provide a default
-configuration for the web browser in
-#{config/chroot_local-includes/etc/iceweasel/profile/}#, or additional
-support packages for viewing various kinds of web content, but we leave this
-as an exercise for the reader.
-
-Build the image, again as superuser, keeping a log as in {Tutorial
-1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Again, verify the image is OK and test, as in {Tutorial 1}#tutorial-1.
-
-2~tutorial-3 Tutorial 3: A personalized image
-
-*{Use case:}* Create a project to build a personalized image, containing your favourite software to take with you on a USB stick wherever you go, and evolving in successive revisions as your needs and preferences change.
-
-Since we will be changing our personalized image over a number of revisions,
-and we want to track those changes, trying things experimentally and
-possibly reverting them if things don't work out, we will keep our
-configuration in the popular #{git}# version control system. We will also
-use the best practice of autoconfiguration via #{auto}# scripts as described
-in {Managing a configuration}#managing-a-configuration.
-
-3~ First revision
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Edit #{auto/config}# to read as follows:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-First, #{--architecture 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}# 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:
-
-code{
-
- # lb build
-
-}code
-
-Note that unlike in the first two tutorials, we no longer have to type
-#{2>&1 | tee binary.log}# as that is now included in #{auto/build}#.
-
-Once you've tested the image (as in {Tutorial 1}#tutorial-1) and are
-satisfied it works, it's time to initialize our #{git}# repository, adding
-only the auto scripts we just created, and then make the first commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Second revision
-
-In this revision, we're going to clean up from the first build, add the
-#{vlc}# package to our configuration, rebuild, test and commit.
-
-The #{lb clean}# command will clean up all generated files from the previous
-build except for the cache, which saves having to re-download packages. This
-ensures that the subsequent #{lb build}# will re-run all stages to
-regenerate the files from our new configuration.
-
-code{
-
- # lb clean
-
-}code
-
-Now edit #{auto/config}# to add the #{vlc}# package:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Build again:
-
-code{
-
-# lb build
-
-}code
-
-Test, and when you're satisfied, commit the next revision:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Of course, more complicated changes to the configuration are possible,
-perhaps adding files in subdirectories of #{config/}#. When you commit new
-revisions, just take care not to hand edit or commit the top-level files in
-#{config}# containing #{LB_*}# variables, as these are build products, too,
-and are always cleaned up by #{lb clean}# and re-created with #{lb config}#
-via their respective #{auto}# scripts.
-
-We've come to the end of our tutorial series. While many more kinds of
-customization are possible, even just using the few features explored in
-these simple examples, an almost infinite variety of different images can be
-created. The remaining examples in this section cover several other use
-cases drawn from the collected experiences of users of Debian Live.
-
-2~ A VNC Kiosk Client
-
-*{Use case:}* Create an image with live-build to boot directly to a VNC server.
-
-Make a build directory and create a skeletal configuration in it built
-around the standard-x11 list, including #{gdm3}#, #{metacity}# and
-#{xtightvncviewer}#, disabling recommends to make a minimal system:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Create the directory #{/etc/skel}# and put a custom #{.xsession}# in it for
-the default user that will launch metacity and start xvncviewer, connecting
-to port #{5901}# on a server at #{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Build the image:
-
-code{
-
- # lb build
-
-}code
-
-Enjoy.
-
-2~ A base image for a 128M USB key
-
-*{Use case:}* Create a standard image with some components removed in order to fit on a 128M USB key with space left over to use as you see fit.
-
-When optimizing an image to fit a certain media size, you need to understand
-the tradeoffs you are making between size and functionality. In this
-example, we trim only so much as to make room for additional material within
-a 128M media size, but without doing anything to destroy integrity of the
-packages contained within, such as the purging of locale data via the
-#{localepurge}# package, or other such "intrusive" optimizations. Of
-particular note, you should not use #{--bootstrap-flavour minimal}# unless
-you really know what you're doing, as omitting priority #{important}#
-packages will most likely produce a broken live system.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Now, build the image in the usual way:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-On the author's system at time of writing, the above configuration produced
-a 78Mbyte image. This compares favourably with the 166Mbyte image produced
-by the default configuration in {Tutorial 1}#tutorial-1.
-
-The biggest space-saver here, compared to building a standard image on an
-#{i386}# architecture system, is to select only the #{486}# kernel flavour
-instead of the default #{-k "486 686"}#. Leaving off APT's indices with
-#{--binary-indices false}# also saves a fair amount of space, the tradeoff
-being that you need to #{apt-get update}# before using apt in the live
-system. Choosing the #{minimal}# package list leaves out the large
-#{locales}# package and associated utilities. Dropping recommended packages
-with #{--apt-recommends false}# saves some additional space, at the expense
-of omitting some packages you might otherwise expect to be there, such as
-#{firmware-linux-free}# which may be needed to support certain hardware. The
-remaining options shave off additional small amounts of space. It's up to
-you to decide if the functionality that is sacrificed with each optimization
-is worth the loss in functionality.
-
-2~ A localized KDE desktop and installer
-
-*{Use case:}* Create a KDE desktop image, localized for Brazilian Portuguese and including an installer.
-
-We want to make an iso-hybrid image for i386 architecture using our
-preferred desktop, in this case KDE, containing all of the same packages
-that would be installed by the standard Debian installer for KDE.
-
-Our initial problem is the discovery of the names of the appropriate
-tasks. Currently, live-build cannot help with this. While we might get lucky
-and find this by trial-and-error, there is a tool, #{grep-dctrl}#, which can
-be used to dig it out of the task descriptions in tasksel-data, so to
-prepare, make sure you have both of those things:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Now we can search for the appropriate tasks, first with:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-By this command, we discover the task is called, plainly enough,
-brazilian-portuguese. Now to find the related tasks:
-
-code{
-
- $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-We will use the experimental #{--language}# option, as live-build happens to
-include #{syslinux}# templates for pt_BR (see {Desktop and language
-tasks}#desktop-and-language-tasks for details). And at boot time we will
-generate the pt_BR.UTF-8 locale and select the pt-latin1 keyboard
-layout. Now let's put the pieces together:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Note that we have included the #{debian-installer-launcher}# package to
-launch the installer from the live desktop, and have also specified the 486
-flavour kernel, as it is currently necessary to make the installer and live
-system kernels match for the launcher to work properly.
diff --git a/manual/de/user_installation.ssi b/manual/de/user_installation.ssi
deleted file mode 100644
index badc83f..0000000
--- a/manual/de/user_installation.ssi
+++ /dev/null
@@ -1,174 +0,0 @@
-:B~ Installation
-
-1~installation Installation
-
-2~requirements Requirements
-
-Building Debian Live images has very few system requirements:
-
-_* Super user (root) access
-
-_* An up-to-date version of live-build
-
-_* A POSIX-compliant shell, such as /{bash}/ or /{dash}/.
-
-_* /{debootstrap}/ or /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Note that using Debian or a Debian-derived distribution is not required -
-live-build will run on almost any distribution with the above requirements.
-
-2~installing-live-build Installing live-build
-
-You can install live-build in a number of different ways:
-
-_* From the Debian repository
-
-_* From source
-
-_* From snapshots
-
-If you are using Debian, the recommended way is to install live-build via
-the Debian repository.
-
-3~ From the Debian repository
-
-Simply install live-build like any other package:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-or
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ From source
-
-live-build is developed using the Git version control system. On Debian
-based systems, this is provided by the /{git}/ package. To check out the
-latest code, execute:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-You can build and install your own Debian package by executing:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Now install whichever of the freshly built #{.deb}# files you were
-interested in, e.g.
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-You can also install live-build directly to your system by executing:
-
-code{
-
- # make install
-
-}code
-
-and uninstall it with:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ From 'snapshots'
-
-If you do not wish to build or install live-build from source, you can use
-snapshots. These are built automatically from the latest version in Git and
-are available on http://live.debian.net/debian/.
-
-2~ live-boot and live-config
-
-*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes. If you only want the documentation, you may now install the live-boot-doc and live-config-doc packages separately.
-
-3~ From the Debian repository
-
-Both live-boot and live-config are available from the Debian repository as
-per {Installing live-build}#installing-live-build.
-
-3~ From source
-
-To use the latest source from git, you can follow the process below. Please
-ensure you are familiar with the terms mentioned in {Terms}#terms.
-
-_* Checkout the live-boot and live-config source
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Consult the live-boot and live-config man pages for details on customizing
-if that is your reason for building these packages from source.
-
-_* Build live-boot and live-config .deb files
-
-You must build either on your target distribution or in a chroot containing
-your target platform: this means if your target is Squeeze then you should
-build against Squeeze.
-
-Use a personal builder such as /{pbuilder}/ or /{sbuild}/ if you need to
-build #{live-boot}# for a target distribution that differs from your build
-system. For example, for Squeeze live images, build #{live-boot}# in a
-Squeeze chroot. If your target distribution happens to match your build
-system distribution, you may build directly on the build system using
-#{dpkg-buildpackage}# (provided by the /{dpkg-dev}/ package):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Use all generated .deb files
-
-As live-boot and live-config are installed by live-build system, installing
-the packages in the host system is not sufficient: you should treat the
-generated .deb files like any other custom packages. Please see {Customizing
-package installation}#customizing-package-installation for more
-information. You should pay particular attention to {Additional
-repositories}#additional-repositories.
-
-3~ From 'snapshots'
-
-You can let live-build automatically use the latest snapshots of live-boot
-and live-config by configuring a third-party repository in your live-build
-configuration directory. Assuming you have already created a configuration
-tree in the current directory with #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/de/user_managing_a_configuration.ssi b/manual/de/user_managing_a_configuration.ssi
deleted file mode 100644
index 999c508..0000000
--- a/manual/de/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,94 +0,0 @@
-:B~ Managing a configuration
-
-1~managing-a-configuration Managing a configuration
-
-This chapter explains how to manage a live configuration from initial
-creation, through successive revisions and successive releases of both the
-live-build software and the live image itself.
-
-2~ Use auto to manage configuration changes
-
-Live configurations rarely are perfect on the first try. You'll likely need
-to make a series of revisions until you are satisfied. However,
-inconsistencies can creep into your configuration from one revision to the
-next if you aren't careful. The main problem is, once a variable is given a
-default value, that value will not be recomputed from other variables that
-may change in later revisions.
-
-For example, when the distribution is first set, many 'dependent' variables
-are given default values that suit that distribution. However, if you later
-decide to change the distribution, those dependent variables continue to
-retain old values that are no longer appropriate.
-
-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 #{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).
-
-2~ Example auto scripts
-
-Use auto script examples such as the following as the starting point for
-your new live-build configuration. Take note that when you call the #{lb}#
-command that the auto script wraps, you must specify #{noauto}# as its
-parameter to ensure that the auto script isn't called again,
-recursively. Also, don't forget to ensure the scripts are executable
-(e.g. #{chmod 755 auto/*}#).
-
-#{auto/config}#
-
-code{
-
- #!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-We now ship example auto scripts with live-build based on the examples
-above. You may copy those as your starting point.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Edit #{auto/config}#, changing or adding any options as you see fit. In the
-example above, #{--packages-lists standard}# is set to the default
-value. Change this to an appropriate value for your image (or delete it if
-you want to use the default) and add any additional options in continuation
-lines that follow.
diff --git a/manual/de/user_overview.ssi b/manual/de/user_overview.ssi
deleted file mode 100644
index ddb3b58..0000000
--- a/manual/de/user_overview.ssi
+++ /dev/null
@@ -1,158 +0,0 @@
-:B~ Overview of tools
-
-1~overview-of-tools Overview of tools
-
-This chapter contains an overview of the three main tools used in building
-Debian Live systems: live-build, live-boot and live-config.
-
-2~live-build live-build
-
-live-build is a collection of scripts to build Debian Live systems. These
-scripts are also referred to as "commands".
-
-The idea behind live-build is to be a framework that uses a configuration
-directory to completely automate and customize all aspects of building a
-Live image.
-
-Many concepts are similar to those in the debhelper Debian package tools
-written by Joey Hess:
-
-_* The scripts have a central location for configuring their operation. In
-debhelper, this is the #{debian/}# subdirectory of a package tree. For
-example, dh_install will look, amongst others, for a file called
-#{debian/install}# to determine which files should exist in a particular
-binary package. In much the same way, live-build stores its configuration
-entirely under a #{config/}# subdirectory.
-
-_* 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.
-
-The remainder of this section discusses the three most important commands:
-
-_* *{lb config}*: Responsible for initializing a Live system configuration
-directory. See {The lb config command}#lb-config for more information.
-
-_* *{lb build}*: Responsible for starting a Live system build. See {The lb
-build command}#lb-build for more information.
-
-_* *{lb clean}*: Responsible for removing parts of a Live system build. See
-{The lb clean command}#lb-clean for more information.
-
-3~lb-config The #{lb config}# command
-
-As discussed in {live-build}#live-build, the scripts that make up live-build
-read their configuration with the #{source}# command from a single directory
-named #{config/}#. As constructing this directory by hand would be
-time-consuming and error-prone, the #{lb config}# command can be used to
-create skeleton configuration folders.
-
-Issuing #{lb config}# without any arguments creates a #{config/}#
-subdirectory which it populates with some default settings:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-Using #{lb config}# without any arguments would be suitable for users who
-need a very basic image, or who intend to later provide a more complete
-configuration via auto/config (see {Managing a
-configuration}#managing-a-configuration for details).
-
-Normally, you will want to specify some options. For example, to include the
-'gnome' package list in your configuration:
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-It is possible to specify many options, such as:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-A full list of options is available in the #{lb_config}# man page.
-
-3~lb-build The #{lb build}# command
-
-The #{lb build}# command reads in your configuration from the config/
-directory. It then runs the lower level commands needed to build your Live
-system.
-
-3~lb-clean The #{lb clean}# command
-
-It is the job of the #{lb clean}# command to remove various parts of a build
-so subsequent builds can start from a clean state. By default, #{chroot}#,
-#{binary}# and #{source}# stages are cleaned, but the cache is left
-intact. Also, individual stages can be cleaned. For example, if you have
-made changes that only affect the binary stage, use #{lb clean --binary}#
-prior to building a new binary. See the #{lb_clean}# man page for a full
-list of options.
-
-2~live-boot The live-boot package
-
-live-boot is a collection of scripts providing hooks for the
-initramfs-tools, used to generate an initramfs capable of booting live
-systems, such as those created by live-build. This includes the Debian Live
-ISOs, netboot tarballs, and USB stick images.
-
-At boot time it will look for read-only media containing a "/live" directory
-where a root filesystem (often a compressed filesystem image like squashfs)
-is stored. If found, it will create a writable environment, using aufs, for
-Debian like systems to boot from.
-
-More information on initial ramfs in Debian can be found in the Debian Linux
-Kernel Handbook at http://kernel-handbook.alioth.debian.org/ in the chapter
-on initramfs.
-
-2~live-config The live-config package
-
-live-config consists of the scripts that run at boot time after live-boot to
-configure the live system automatically. It handles such tasks as setting
-the hostname, locales and timezone, creating the live user, inhibiting cron
-jobs and performing autologin of the live user.
diff --git a/manual/es/_sisu/.empty b/manual/es/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/es/_sisu/image/.empty b/manual/es/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/es/_sisu/sisurc.yml b/manual/es/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/es/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/es/_sisu/skin/doc/skin_debian-live.rb b/manual/es/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/es/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/es/about_manual.ssi b/manual/es/about_manual.ssi
deleted file mode 100644
index 9e7d698..0000000
--- a/manual/es/about_manual.ssi
+++ /dev/null
@@ -1,305 +0,0 @@
-:B~ Acerca de este manual
-
-1~about-manual Acerca de este manual
-
-El objetivo principal de este manual es servir como único punto de acceso a
-toda la documentación referente al projecto Debian Live. Está principalmente
-enfocado a ayudar en la creación de un sistema en vivo y no está dirigido al
-usuario final de estos sistemas. Un usuario final puede encontrar
-información útil en las siguentes secciones: {Conceptos básicos}#the-basics
-cubre la preparación de las imágenes para arrancar un sistema desde un medio
-de almacenamiento o desde red local. {Personalización del comportamiento en
-tiempo de ejecución}#customizing-run-time-behaviours describe alguna de las
-opciones que pueden especificarse en el indicador de arranque, como pueden
-ser la selección de la distribución del teclado, las variantes locales o la
-persistencia.
-
-Algunos de los comandos mencionados en el texto deben ser ejecutados con
-privilegios de superusuario, que pueden ser obtenidos accediendo a la cuenta
-de root mediante la orden #{su}# o mediante la orden #{sudo}#. Para
-distinguir las ordenes que deben ser ejecutadas como usuario no privilegiado
-de las que si requieren privilegios de superusuario se ha prefijado con
-#{$}# las primeras y con #{#}# las segundas. Estos símbolos no son parte de
-la orden.
-
-2~ Para el impaciente.
-
-Aunque se cree que todo lo descrito en este manual es importante para la
-mayoría de los usuarios, es cierto que hay mucho material a interiorizar y
-que los usuarios desean experimentar con las herramientas de forma rápida y
-satisfactoria antes de entrar en detalles. Ésta es la razón por la que se
-presentan tres tutoriales en la sección {Ejemplos}#examples pensados para
-aprender a configurar y construir imágenes de sistemas en vivo de forma
-básica. Se deberá leer primero {Uso de ejemplos}#using-the-examples, seguido
-de {Tutorial 1: Una imagen estándar}#tutorial-1 y {Tutorial 2: Una utilidad
-de navegador web}#tutorial-2, para finalizar con {Tutorial 3: Una imagen
-personalizada}#tutorial-3. Al final de estos tutoriales, el lector tendrá
-una visión de lo que se puede hacer con Debian Live. Se anima a profundizar
-en el estudio del manual con la lectura detenida del siguiente capítulo,
-{Conceptos básicos}#the-basics, y de una manera más somera el capítulo {La
-creación de una imagen netboot}#building-netboot-image, para acabar con la
-lectura de {Descripción general de la
-personalización}#customization-overview y los capítulos que le siguen. Se
-espera que, en este punto, el lector esté lo suficientemente motivado con lo
-que se puede hacer con Debian Live para leer el resto del manual, de
-principio a fin.
-
-2~terms Términos
-
-_* *{Sistema en vivo}*: Se entiende por sistema en vivo aquel sistema
-operativo que se puede arrancar sin instalación previa en el disco duro. Un
-sistema en vivo no altera ningún sistema operativo previamente instalado ni
-ningún fichero existente en el disco duro de la máquina a menos que se le
-instruya para hacerlo. Los sistemas en vivo son arrancados típicamente desde
-medios extraíbles como CD, DVD o llaves USB. Algunos pueden también arrancar
-desde la red local.
-
-_* *{Debian Live}*: Es un subproyecto de Debian que mantiene los paquetes
-Debian live-boot, live-build, live-config y live-manual.
-
-_* *{Sistema Debian Live}*: Es un sistema en vivo que utiliza programas del
-sistema operativo Debian y que puede ser arrancado desde medios extraíbles
-como CD, DVD o llaves USB, desde red local (mediante imágenes netboot) o
-desde Internet (utilizando la opción de arranque #{fetch=URL}#).
-
-_* *{Sistema huésped}*: Es el conjunto de herramientas y equipo utilizado
-para crear el sistema en vivo.
-
-_* *{Sistema objetivo}*: Es el conjunto de herramientas y equipo donde se
-ejecutará el sistema en vivo.
-
-_* *{live-boot}*: Es una colección de scripts que serán responsables de
-arrancar el sistema en vivo. live-boot fue anteriormente una parte del
-paquete live-initramfs.
-
-_* *{live-build}*: Es una colección de scripts utilizados para construir
-sistemas Debian Live personalizados. live-build fue conocido anteriormente
-como live-helper, y en una versión anterior como live-package.
-
-_* *{live-config}*: Es una colección de scripts utilizados para configurar
-un sistema en vivo durante el proceso de arranque. live-config fue
-anteriormente parte del paquete live-initramfs.
-
-_* *{live-manual}*: Este documento forma parte de un paquete llamado
-live-manual.
-
-_* *{Instalador de Debian (Debian Installer o d-i)}*: Es el mecanismo
-oficial de instalación para la distribución Debian.
-
-_* *{Parámetros de arranque}*: Parámetros que son entregados al gestor de
-arranque (bootloader) para modificar el comportamiento del kernel o del
-conjunto de scripts live-config. Son llamados también Parámetros de kernel u
-Opciones de arranque.
-
-_* *{chroot}*: El programa chroot, #{chroot(8)}#, permite ejecutar
-diferentes instancias de un entorno GNU/Linux en un solo sistema de manera
-simultánea sin necesidad de reiniciar el sistema.
-
-_* *{Imagen binaria}*: Es un fichero binario que contiene el sistema en
-vivo. Su nombre puede ser binary.iso o binary.img dependiendo de su formato.
-
-_* *{Distribución objetivo}*: Es la versión de la distribución Debian en la
-cual estará basado el sistema en vivo que puede diferir de la versión de la
-distribución en el sistema huésped.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Son los nombres clave
-de las diferentes versiones de distribución Debian. En el momento de
-escribir este documento, Squeeze es la actual versión *{stable}* o estable,
-Wheezy es la actual versión *{testing}* o en pruebas. Sid es y será siempre
-sinónimo de versión *{unstable}* o inestable. A lo largo de todo el manual
-se usan los nombres en clave de las versiones ya que las herramientas
-también los usan.
-
-La distribución *{stable}* contiene la última distribución Debian
-oficialmente publicada. La distribución *{testing}* está en la rampa de
-salida para ser la próxima distribución *{stable}*. La principal ventaja de
-utilizar esta distribución es que tiene versiones de programas más recientes
-si se compara con la versión *{stable}*. La distribución *{unstable}* es
-dónde se realiza el desarrollo de Debian. Generalmente esta distribución es
-usada por los desarrolladores y aquellos que les gusta vivir al filo de lo
-imposible.
-
-2~ Autores
-
-Lista de autores (en orden alfabético):
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Cómo contribuir en este documento
-
-Este manual se ha creado como un proyecto comunitario y cualquier propuesta
-para su mejora u otras contribuciones son siempre bienvenidas. La mejor
-forma de hacer una contribución es enviarla a la lista de correo. Ver la
-sección {Contacto}#contact para más información.
-
-Cuando se envía una contribución se debe identificar claramente su copyright
-e incluir la declaración de licencia. Se hace notar que para ser aceptada,
-una contribución debe ser licenciada bajo la misma licencia que el resto del
-documento, esto es, GPL versión 3 o posterior.
-
-Los originales de este manual se mantienen utilizando el sistema de control
-de versiones Git. Se puede obtener la copia más actualizada ejecutando la
-siguiente orden:
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Antes de enviar una contribución se debería realizar una visualización del
-trabajo realizado. Para ello asegurarse de tener instalados los paquetes
-necesarios para la construcción del live-manual ejecutando la siguiente
-orden:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-Se puede realizar la construcción del manual posicionándose en el directorio
-de nivel superior, o sea, en el directorio clonado mediante Git y ejecutando
-la siguiente orden:
-
-
-code{
-
- $ make build
-
-}code
-
-Ya que la construcción del manual para todos los idiomas soportados tarda un
-rato, puede ser mejor crear un solo idioma. Esto puede realizarse ejecutando
-la siguiente orden:
-
-
-code{
-
-$ make build LANGUAGES=en
-
-}code
-
-3~ Aplicación de parches
-
-Cualquiera puede hacer una entrega en el repositorio. Sin embargo, a la hora
-de hacer grandes cambios, es conveniente enviarlos a la lista de correo para
-discutirlos primero. Para realizar una entrega al repositorio se debe seguir
-el siguiente procedimiento:
-
-
-_* Obtener la clave pública de entrega:
-
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Añadir la siguiente sección en el fichero de configuración de
-openssh-client:
-
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Obtener un clon del manual mediante git utilizando ssh:
-
-
-code{
-
- $ git clone git at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Asegurarse de enviar los cambios a la rama debian-next y no a la rama
-Debian.
-
-_* Después de editar los ficheros que se deseen en #{manual/en/}#, ejecutar
-«make commit» en el directorio superior para sanear los ficheros y
-actualizar los ficheros de traducciones:
-
-
-code{
-
- $ make commit
-
-}code
-
-_* Una vez se ha saneado, se deberán entregar los cambios. Se deberá
-escribir un mensaje de entrega que consistirá en una o varias frases en
-ingles, comenzando con una letra mayúscula y acabando con un punto final. Es
-habitual comenzar estas frases con la forma
-'Fixing/Adding/Removing/Correcting/Translating', por ejemplo:
-
-
-code{
-
-$ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Para finalizar se realizará la entrega al servidor utilizando el
-siguiente comando:
-
-code{
-
- $ git push
-
-}code
-
-3~ Traducciones
-
-Para enviar una traducción para un nuevo idioma, se deben seguir los
-siguientes pasos:
-
-_* Traducir los ficheros about_manual.ssi.pot, about_project.ssi.pot e
-index.html.in.pot al idioma deseado con cualquier editor (como puede ser
-poedit) y enviarlos a la lista de correos. Una vez hayan sido revisados, el
-idioma será añadido al manual, (añadiendo los ficheros .po) y se activará en
-el autobuild.
-
-_* Una vez que el nuevo idioma haya sido añadido, se puede comenzar la
-traducción de todos los ficheros .po exisitentes en #{manual/po/}# de manera
-aleatoria.
-
-_* No se debe olvidar la ejecución del comando #{make commit}# para asegurar
-que los manuales traducidos son actualizados desde los ficheros .po, antes
-de realizar la entrega mediante #{git commit -a}# y #{git push}#.
diff --git a/manual/es/about_project.ssi b/manual/es/about_project.ssi
deleted file mode 100644
index a0afe14..0000000
--- a/manual/es/about_project.ssi
+++ /dev/null
@@ -1,115 +0,0 @@
-:B~ Acerca del Proyecto Debian Live
-
-1~about-project Acerca del Proyecto Debian Live
-
-2~ Motivación
-
-3~ Desventajas en los sistemas Live actuales
-
-Cuando se comenzó el trabajo en Debian Live, ya existían varios Sistemas
-Live disponibles basados en la distribución Debian y todos hacian un buen
-trabajo. Desde la persectiva de Debian, la mayoría de estos sistemas tenían
-alguna de estas desventajas:
-
-_* No eran proyectos de Debian y por lo tanto no contaban con soporte desde
-dentro de Debian.
-
-_* Mezclaban paquetes de diferentes versiones, por ejemplo *{testing}* y
-*{unstable}*.
-
-_* Solamente soportaban la arquitectura i386.
-
-_* Modificaban el comportamiento y/o la apariencia de los paquetes,
-eliminando contenido para reducirlos de tamaño.
-
-_* Incluían paquetes de fuera del archivo de Debian.
-
-_* Utilizaban kernels personalizados con parches que no eran parte de
-Debian.
-
-_* Eran demasiado lentos, debido a su gran tamaño, para ser utilizados como
-sistemas de rescate.
-
-_* No disponían de diferentes medios de instalación, como CDs, DVDs, llaves
-USB o imágenes de arranque por red netboot.
-
-3~ El porqué de crear un Sistema Live propio.
-
-Debian es el Sistema Operativo Universal: Debian tiene un Sistema Live para
-mostrar y representar el auténtico y verdadero Debian con las siguientes
-ventajas fundamentales:
-
-_* Debería ser un subproyecto de Debian.
-
-_* Refleja el estado (actual) de una versión Debian.
-
-_* Se ejecuta en tantas arquitecturas como es posible.
-
-_* Consiste solamente de paquetes Debian sin modificar.
-
-_* No contiene ningún paquete que no forma parte del archivo de Debian.
-
-_* Utiliza kernels que provienen de Debian inalterados sin parches
-adicionales.
-
-2~ Filosofía
-
-3~ Solamente paquetes sin modificación alguna de Debian «main»
-
-Solamente se utilizarán paquetes del repositorio de Debian de la sección
-«main». La sección non-free no es parte de Debian y por lo tanto no puede
-ser utilizada de ninguna de las maneras para generar imágenes de sistema
-oficiales.
-
-No se modificará ningún paquete. Siempre que se necesite modificar algo, se
-hará en coordinación con el correspondiente mantenedor del paquete en
-Debian.
-
-Como una excepción, los paquetes del proyecto como son live-boot, live-build
-o live-config, pueden ser utilizados temporalmente desde el repositorio del
-proyecto, por razones de desarrollo (por ejemplo para crear instantaneas de
-pruebas). Estos paquetes serán actualizados en Debian de manera regular.
-
-3~ Sin configuración especial para el Sistema Live
-
-En esta fase, no se creará o instalarán configuraciones alternativas o de
-ejemplo. Se utilizarán todos los paquetes con su configuración por defecto,
-tal y como quedan después de una instalación normal de Debian.
-
-Siempre que se necesite una configuración diferente a la de por defecto, se
-hará en coodinación con el mantenedor del paquete Debian correspondiente.
-
-En #{lb config}# se emplea un sistema para configurar paquetes que utiliza
-debconf (mediante el uso de la opción --preseed FICHERO), permitiendo la
-personalización de la configuración de los paquetes que van a ser instalados
-en la imagen Debian Live que se genere, pero las imágenes Live oficiales
-solamente utilizarán la configuración por defecto.
-
-Excepción: Es esencial realizar unos pocos cambios para que un sistema pueda
-funcionar en vivo (como por ejemplo configurar pam para permitir
-contraseñas vacias). Estos cambios esenciales se deben mantener tan pequeños
-como sea posible y deberán ser mezclados en el repositorio Debian siempre
-que exista la posibilidad.
-
-2~contact Contacto
-
-_* *{Lista de correo}*: El sistema de contacto principal del proyecto es la
-lista de correo en http://lists.debian.org/debian-live/. Se puede enviar un
-correo a la lista directamente dirigiéndolo a
-debian-live at lists.debian.org. Los archivos históricos de la lista están
-disponibles en http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: Un número importante de usuarios y desarrolladores suele estar
-presente en el canal #debian-live de irc.debian.org (OFTC). Por favor, se
-debe ser paciente cuando se espera una respuesta en el IRC. Si la respuesta
-no llega, se puede enviar la pregunta a la lista de correos.
-
-_* *{BTS}*: El sistema de gestión de errores de Debian (BTS) contiene
-detalles de problemas enviados por usuarios y desarrolladores. Los errores
-están numerados y se mantiene un registro hasta que son reparados. Si se
-desea más información ver {Informes de errores}#bugs.
-
-_* *{Wiki}*: El wiki de Debian Live en http://wiki.debian.org/DebianLive es
-el lugar donde obtener información, discutir sobre la aplicación de
-tecnologías y de documentar herramientas para los sistemas Debian Live que
-vayan más allá del ámbito de este documento.
diff --git a/manual/es/index.html.in b/manual/es/index.html.in
deleted file mode 100644
index ccc51a1..0000000
--- a/manual/es/index.html.in
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-
-<head>
- <title>Proyecto Debian Live</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Manual de Debian Live</h2>
-
- <p>
- Por favor, leer previamente <a
-href="html/about-manual.html#how-to-contribute">como contribuir</a> para
-conocer como reportar errores, omisiones, parches y sugerencias a este
-manual, utilizando la lista de correos <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>.
- </p>
-
- <h3>Formatos Disponibles</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">una página por capítulo</a>, <a
-href="html/live-manual.html">todo el manual en una página</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 vertical</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 apaisado</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">Carta (letter) vertical</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">Carta (letter) apaisado</a></li>
- <li><a href="txt/live-manual.txt">Texto sin formato</a></li>
- </ul>
-
- <p>
- Último cambio: @DATE_CHANGE@<br />
- Última generación: @DATE_BUILD@
- </p>
-
- <h3>Originales</h3>
-
- <p>
- Los originales de este manual están disponibles en el repositorio <a
-href="http://git.or.cz/">Git</a> de live.debian.net.
- </p>
-
- <ul>
- <li>Navegar: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Aviso Legal</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/es/live-manual.ssm b/manual/es/live-manual.ssm
deleted file mode 100644
index 72ad1d9..0000000
--- a/manual/es/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Manual Debian Live
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: Este programa es software libre: puede ser redistribuido y / o modificado bajo los términos de la GNU General Public License publicada por la Free Software Foundation, bien de la versión 3 de la Licencia, o (a su elección) cualquier versión posterior. <br><br> Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA, incluso sin la garantía implícita de COMERCIALIZACIÓN o IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Consulte la GNU General Public License para más detalles. <br><br> Debería haber recibido una copia de la General Public License GNU junto con este programa. Si no, vea http://www.gnu.org/licenses/. <br><br> El texto completo de la GNU Licencia Pública General se pueden encontrar en /usr/share/common-licenses/GPL-3
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ Acerca de este manual
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ Usuario
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Proyecto
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Ejemplos
-
-<< user_examples.ssi
diff --git a/manual/es/project_bugs.ssi b/manual/es/project_bugs.ssi
deleted file mode 100644
index 6752d82..0000000
--- a/manual/es/project_bugs.ssi
+++ /dev/null
@@ -1,211 +0,0 @@
-B~ Cómo informar acerca de errores.
-
-1~bugs Informes de errores.
-
-Debian Live está lejos de ser perfecto, pero queremos que sea lo más
-perfecto posible - con tu ayuda. No dudar en informar de un error: es mejor
-llenar un informe dos veces que no hacerlo nunca. Sin embargo, este capítulo
-incluye recomendaciones sobre cómo presentar buenos informes de errores.
-
-Para los impacientes:
-
-_* Primero, siempre se debe comprobar el estado actualizado de la imagen en
-busca de problemas conocidos en la página web http://live.debian.net/.
-
-_* Se debe intentar reproducir el error con las *{versiones más recientes}*
-de live-build, live-boot, y live-config antes de presentar un informe de
-errores.
-
-_* Se debe intentar dar la *{información tan específica como sea posible}*
-acerca del error. Esto incluye (al menos) la versión de live-build,
-live-boot, y live-config utilizada y la distribución del sistema en vivo
-que está construyendo.
-
-2~ Problemas conocidos
-
-Debido a que Debian *{testing}* y Debian *{unstable}* están cambiando
-continuamente, no siempre es posible crear un sistema con éxito cuando se
-especifica cualquiera de estas dos versiones.
-
-% FIXME:
-
-Si esto causa mucha dificultad, no se debe crear un sistema basado en
-*{testing}* o *{unstable}*, sino que debe utilizarse *{stable}*. Live-build
-siempre utiliza por defecto la versión *{stable}* .
-
-Los problemas detectados se especifican en la sección 'status' de la página
-web http://live.debian.net/.
-
-Está fuera del alcance de este manual enseñar cómo identificar y solucionar
-correctamente problemas de los paquetes de las distribuciones en desarrollo,
-sin embargo, hay dos cosas que siempre se puede intentar: Si se detecta un
-error de creación cuando la distribución de destino es *{testing}*, se debe
-intentar con *{unstable}*. Si *{unstable}* no funciona bien, se debe volver
-a *{testing}* haciendo un pin con la nueva versión del paquete de
-*{unstable}* (véase {APT pinning}#apt-pinning para más detalles).
-
-2~ Reconstruir desde cero
-
-Para asegurarse de que un error en particular no es causado por crear el
-sistema basándose en los datos de un sistema anterior, se debe reconstruir
-el sistema en vivo entero, desde el principio y comprobar si el error es
-reproducible.
-
-2~ Utilizar paquetes actualizados
-
-Utilizar paquetes obsoletos puede causar problemas importantes al tratar de
-reproducir (y en última instancia, solucionar) el problema. Hay que
-asegurarse de que el sistema de construcción está actualizado y cualquier
-paquete que se incluya en la imagen esté también al día .
-
-2~collect-information Recopilar información
-
-Se debe proporcionar información suficiente con el informe. Como mínimo, la
-versión exacta de live-build donde se encuentra el error y los pasos para
-reproducirlo. Se debe utilizar el sentido común e incluir cualquier
-información pertinente si se cree que podría ayudar a resolver el problema.
-
-Para sacar el máximo provecho de un informe de errores, se requerirá al
-menos la siguiente información:
-
-_* Arquitectura del sistema anfitrión
-
-_* La versión de live-build del sistema anfitrión.
-
-_* Versión de live-boot en el sistema en vivo.
-
-_* Versión de live-config en el sistema en vivo.
-
-_* Versión de #{debootstrap}# y/o #{cdebootstrap}# en el sistema anfitrión.
-
-_* Arquitectura del sistema en vivo.
-
-_* Distribución del sistema en vivo.
-
-_* Versión del kernel en el sistema en vivo.
-
-Se puede generar un log del proceso de creación mediante el comando
-#{tee}#. Se recomienda hacer esto de forma automática con un script
-#{auto/build}#; (ver {Gestionar una configuración}#managing-a-configuration
-para más detalles).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-En el momento del arranque, live-boot guarda un log en #{/var/log/live.log}#
-(o #{/var/log/live-boot.log}#).
-
-Además, para descartar otros errores, siempre es una buena idea comprimir en
-un .tar el directorio #{config/}# y subirlo a algún lugar, para que el
-equipo de Debian Live pueda reproducir el error (*{No}* se debe enviar como
-documento adjunto a la lista de correo). Si esto es difícil (por ejemplo,
-debido a su tamaño) se puede utilizar la salida del comando #{lb config
---dump}# que produce un resumen del árbol de configuración (es decir, listas
-de archivos de los subdirectorios de #{config /}# pero no los incluye).
-
-Hay que recordar que los informes a enviar se deben hacer en ingles, por lo
-que para generar los logs en este idioma se debe utilizar la variante local
-English, p.ej. ejecutar los comandos de live-build o cualquier otro
-precedidos de #{LC_ALL=C}# o #{LC_ALL=en_US}#.
-
-2~ Aislar el fallo si es posible
-
-Si es posible, aislar el caso del fallo al menor cambio posible que lo
-produzca. No siempre es fácil hacer esto, así que si no se consigue para su
-informe, no hay que preocuparse. Sin embargo, si se planea el ciclo de
-desarrollo bién, con conjuntos de cambios lo bastante pequeños por
-iteración, puede ser posible aislar el problema mediante la construcción de
-una simple «base» de configuración que se ajuste a la configuración actual
-deseada, más el conjunto del cambio que falla añadido. Si resulta difícil
-determinar que cambios produjeron el error, puede ser que se haya incluido
-demasiado en cada conjunto de cambios y se deba desarrollar en incrementos
-más pequeños.
-
-2~ Utilizar el paquete correcto sobre el que informar del error
-
-¿Dónde aparece el error?
-
-3~ En la preinstalación (bootstrap) en tiempo de creación.
-
-live-build arranca primero un sistema Debian básico con #{debootstrap}# o
-#{cdebootstrap}#. Puede fallar dependiendo de la herramienta usada en la
-preinstalación y de la distribución Debian empleada. Si un error aparece en
-este momento, se debe comprobar si está relacionado con un paquete
-específico de Debian (es lo más probable), o si está relacionado con la
-herramienta de preinstalación en sí.
-
-En ambos casos, esto no es un error de Debian Live, sino de Debian en sí
-mismo, por lo cual el equipo de Debian Live no puede solucionarlo
-directamente. Informe del error sobre la herramienta de preinstalación o el
-paquete que falla.
-
-3~ Mientras se instalan paquetes en tiempo de creación.
-
-live-build instala paquetes adicionales del archivo de Debian que pueden
-fallar en función de la distribución Debian utilizada y del estado diario
-del archivo Debian. Se debe comprobar si el error es reproducible en un
-sistema Debian normal, si el fallo aparece en esta etapa.
-
-Si este es el caso, esto no es un error de Debian Live, sino de Debian - se
-debe informar sobre el paquete que falla. Se puede obtener más información
-ejecutando #{debootstrap}# de forma separada del sistema de creación en vivo
-o ejecutando #{lb bootstrap --debug}#.
-
-Además, si se está utilizando una réplica local y/o cualquier tipo de proxy
-y se experimenta un problema, se debe intentar reproducir siempre
-preinstalando desde una réplica oficial.
-
-3~ En tiempo de arranque
-
-Si la imagen no arranca, se debería informar la lista de correo, junto con
-la información solicitada en {Recopilar información}#collect-information. No
-hay que olvidar mencionar, cómo y cuando la imagen falla, en Qemu,
-VirtualBox, VMWare o hardware real. Si se está utilizando una tecnología de
-virtualización de cualquier tipo, se debe probar la imagen en hardware real
-antes de informar de un error. Proporcionar una captura de pantalla del
-error también es muy útil.
-
-3~ En tiempo de ejecución
-
-Si un paquete se ha instalado correctamente, pero falla cuando se ejecuta el
-sistema en vivo, esto es probablemente un error en Debian Live. Sin embargo,
-
-2~ Hacer la investigación
-
-Antes de presentar el informe de errores, buscar en la web el mensaje de
-error en particular o el síntoma que se está percibiendo. Como es muy poco
-probable que sea la única persona que tiene ese problema en concreto,
-siempre existe la posibilidad de que se haya discutido en otras partes y
-exista una posible solución, parche o se haya propuesto una alternativa.
-
-Se debe prestar especial atención a la lista de correo de Debian Live, así
-como su página principal, ya que seguramente tienen la información más
-actualizada. Si esa información existe, se debe incluir la referencia a ella
-en su informe de errores.
-
-Además, se debe comprobar las listas de errores actuales de live-build,
-live-boot, y live-config y verificar si se ha informado ya de algo similar.
-
-2~ Dónde informar de los fallos
-
-El proyecto Debian Live realiza un seguimiento de todos los errores en el
-sistema de seguimiento de fallos de Debian (BTS). Para obtener información
-sobre cómo utilizar el sistema, consultar http://bugs.debian.org/. También
-se puede enviar los errores mediante el comando #{reportbug}# del paquete
-con el mismo nombre.
-
-En general, se debe informar sobre los errores en tiempo de creación en el
-BTS contra el paquete live-build. De los fallos en el tiempo de arranque
-contra el paquete live-boot, y de los errores en tiempo de ejecución contra
-el paquete live-config. Si no se está seguro de qué paquete es el adecuado o
-se necesita más ayuda antes de presentar un informe de errores, lo mejor es
-enviar un mensaje a la lista de correo y el equipo de Debian Live le ayudará
-a resolverlo.
-
-Hay que tener en cuenta que los errores que se encuentran en las
-distribuciones derivadas de Debian (como Ubuntu y otros) *{NO}* deben
-enviarse al BTS de Debian a menos que también se puedan reproducir en un
-sistema Debian usando paquetes oficiales de Debian.
diff --git a/manual/es/project_coding-style.ssi b/manual/es/project_coding-style.ssi
deleted file mode 100644
index a965c1f..0000000
--- a/manual/es/project_coding-style.ssi
+++ /dev/null
@@ -1,150 +0,0 @@
-B~ Estilo de código
-
-1~coding-style Estilo de código
-
-En este capítulo se documenta el estilo de código utilizado en live-boot y
-otros.
-
-2~ Compatibilidad
-
-_* No utilizar sintaxis o semántica que sea única para el intérprete de
-comandos Bash. Por ejemplo, el uso de matrices.
-
-_* Utilizar únicamente el subconjunto POSIX - por ejemplo, usar $(foo) en
-lugar de `foo`.
-
-_* Se puede comprobar las secuencias de comandos con 'sh -n' y
-'checkbashisms'.
-
-2~ Sangrado
-
-_* Utilizar siempre los tabuladores en lugar de espacios.
-
-2~ Ajuste de líneas
-
-_* En general, las líneas contienen 80 caracteres como máximo.
-
-_* Utilizar los saltos de línea al «estilo Linux»:
-
-Mal:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Bien:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* Lo mismo vale para las funciones:
-
-Mal:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Bien:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variables
-
-_* Las variables deben escribirse siempre en letras mayúsculas.
-
-_* Las variables que se utiliza en #{lb config}# siempre comienzan con el
-prefijo #{LB_}#
-
-_* Las variables temporales internas del live-build deben comenzar con el
-prefijo #{\_LB_}#
-
-_* Las variables locales comienzan con el prefijo live-build #{\_\_LB_}#
-
-_* Las variables en relación a un parámetro de arranque en live-config
-comienzan con #{LIVE_}#.
-
-_* Todas las demás variables de live-config comienzan con el prefijo #{_}#
-
-_* Utilizar llaves para las variables, por ejemplo, escribir #{${FOO}}# en
-lugar de #{$FOO}#.
-
-_* Utilizar comillas dobles en las variables para evitar dejar espacios en
-blanco: Escribir #{"${FOO}"}# en lugar de #{${FOO}}#.
-
-_* Por motivos de coherencia, se debe utilizar siempre comillas en la
-asignación de valores a las variables:
-
-Mal:
-
-code{
-
- FOO=bar
-
-}code
-
-Bien:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* Si se utilizan múltiples variables, incluir la expresión completa entre
-comillas dobles:
-
-Mal:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Bien:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Miscelánea
-
-_* Se debe utilizar "#{|}#" (sin comillas) como separador cuando se invoque
-a sed, p.ej. "#{sed -e 's|foo|bar|'}#" (Pero sin las comillas "")
-
-_* No se debe utilizar el comando #{test}# para hacer comparaciones o
-pruebas, usar "#{[}#" "#{]}#" (sin ""); p.ej. "#{if [ -x /bin/foo ]; ...}#"
-en lugar de "#{if test -x /bin/foo; ...}#".
-
-_* Se debe utilizar #{case}# siempre que sea posible en lugar de #{test}#,
-ya que es más fácil de leer y más rápido en la ejecución.
diff --git a/manual/es/project_procedures.ssi b/manual/es/project_procedures.ssi
deleted file mode 100644
index 72722d3..0000000
--- a/manual/es/project_procedures.ssi
+++ /dev/null
@@ -1,144 +0,0 @@
-B~ Procedimientos
-
-1~procedures Procedimientos
-
-Este capítulo documenta los procedimientos dentro del proyecto Debian Live
-para diversas tareas que requieren la cooperación con otros equipos de
-Debian.
-
-2~ Subir Udebs
-
-Antes de enviar una nueva versión de un udeb al d-i svn, uno tiene que
-ejecutar:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Principales lanzamientos
-
-El lanzamiento de una nueva versión estable de Debian involucra a una gran
-cantidad de equipos diferentes que trabajan juntos para conseguirlo. En un
-momento dado, el equipo Live aparece y desarrolla imágenes en vivo del
-sistema. Los requisitos para ello son:
-
-_* Una réplica de las versiones publicadas de los archivos de debian,
-debian-security y debian-volatile a la que pueda acceder el programa creador
-de debian-live (live-build)
-
-_* Es necesario conocer el nombre de la imagen
-(p.ej. debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* Es necesario haber actualizado la lista de paquetes.
-
-_* Es necesario sincronizar los datos de debian-cd (lista de exclusión de
-udeb)
-
-_* Es necesario sincronizar la lista de los paquetes de debian-cd incluidos
-(README.*, doc/*, etc.).
-
-_* Las imágenes se crean y se almacenan en cdimage.debian.org.
-
-2~ Nuevas versiones
-
-_* Una vez más, se necesita una réplica actualizada de Debian,
-debian-security y debian-volatile.
-
-_* Las imágenes se crean y se almacenan en cdimage.debian.org.
-
-_* Correo para enviar anuncios.
-
-3~ Plantilla para anunciar nuevas versiones.
-
-Se puede generar un anuncio de nuevas versiones usando la siguiente
-plantilla y el siguiente comando:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-Revisar el mensaje de correo con cuidado antes de enviarlo a otras personas
-para su corrección.
-
-code{
-
-Imágenes de Debian en vivo para Debian GNU/Linux %major% actualizadas
-
-El proyecto Debian Live se complace en anunciar la disponibilidad de las imágenes en vivo actualizadas para su distribución estable de Debian GNU / Linux %major%
- (nombre en clave "%codename%").
-
- Las imágenes están disponibles para su descarga en:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Esta actualización incorpora las modificaciones introducidas en la nueva versión, %minor%
- la cual añade correcciones para problemas de seguridad a la versión estable
- junto con algunos ajustes para problemas graves. Se puede consultar
- una lista completa de los cambios en:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
-También incluye los siguientes cambios específicos del proyecto Live:
-
- * [INSERTAR CAMBIOS ESPECÍFICOS DEL PROYECTO LIVE AQUI]
- * [INSERTAR CAMBIOS ESPECÍFICOS DEL PROYECTO LIVE AQUI]
- * [LAS CUESTIONES MÁS IMPORTANTES PUEDEN MERECER SU PROPIA SECCIÓN]
-
-
- URLs
- ----
-
-Sitio de descarga de imágenes actualizadas:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
-Página principal del proyecto Debian Live
-
- <http://live.debian.net/>
-
- La distribución estable actual:
-
- <http://ftp.debian.org/debian/dists/stable>
-
-Información acerca de la distribución estable (notas de publicación, errores, etc.):
-
- <http://www.debian.org/releases/stable/>
-
-Anuncios de seguridad e información
-
- <http://www.debian.org/security/>
-
-
- Acerca de Debian
- -------------
-
- El Proyecto Debian es una asociación de desarrolladores de Software Libre que
- ofrecen voluntariamente su tiempo y esfuerzo con el fin de producir el
- sistema operativo libre Debian GNU/Linux.
-
-
- Acerca de Debian Live
- -----------------
-
- Debian Live es un sub-proyecto oficial de Debian que produce sistemas
- Debian que no requieren una instalación clásica. Las imágenes están disponibles
- para CD/DVD, llaves USB y arranque en red PXE, así como
- imágenes de un sistema de ficheros básico para el arranque directamente desde Internet.
-
-
- Información de contacto
- -------------------
-
-Para más información, visitar las páginas web de Debian Live
-<http://live.debian.net/> o bien enviar un correo a
-<debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/es/user_basics.ssi b/manual/es/user_basics.ssi
deleted file mode 100644
index 1a91561..0000000
--- a/manual/es/user_basics.ssi
+++ /dev/null
@@ -1,564 +0,0 @@
-:B~ Conceptos básicos
-
-1~the-basics Conceptos básicos
-
-Este capítulo contiene una breve descripción del proceso de creación de las
-imágenes en vivo y las instrucciones para el uso de los tres tipos de
-imágenes más utilizadas. El tipo de imagen más versátil, #{iso-hybrid}#, se
-puede utilizar en una máquina virtual, en medios ópticos u otros dispositivo
-de almacenamiento USB. En ciertos casos especiales, como para el uso de la
-persistencia («persistence» N. del T.) las imágenes #{usb-hdd}#, pueden ser
-las más adecuadas para dispositivos USB. El capítulo termina con
-instrucciones para crear y usar una imagen de tipo #{red}#, que es un poco
-más complicado debido a la configuración necesaria en el servidor. Es un
-tema ligeramente avanzado para cualquier persona que no esté familiarizada
-con el arranque en red, pero se incluye aquí porque una vez que se realiza
-la instalación, es una forma muy conveniente para probar y desplegar
-imágenes de arranque en red local sin la molestia de tratar con los
-dispositivos de almacenamiento de la imagen.
-
-A lo largo de todo el capítulo se hace a menudo referencia al nombre de las
-imágenes producidas por defecto por live-build. Si se descarga una imagen ya
-creada, el nombre puede variar.
-
-2~what-is-live ¿Qué es un sistema en vivo?
-
-Por lo general, un sistema en vivo se refiere a un sistema operativo que
-arranca en un equipo desde un medio extraíble, como un CD-ROM, dispositivo
-USB, o desde una red, listo para usar sin ningún tipo de instalación en la
-unidad de costumbre, con configuración automática en tiempo de ejecución
-(Ver {Términos}#terms).
-
-Debian Live, es un sistema Debian GNU/Linux, creado para una de las
-arquitecturas soportadas (actualmente amd64, i386, powerpc y sparc). Se
-compone de las siguientes partes:
-
-_* *{Imágen del kernel de Linux}*, normalmente llamada #{vmlinuz*}#
-
-_* *{Imagen del Disco RAM inicial (initrd)}*: Un Disco RAM configurado para
-el arranque de Linux, que incluya los módulos posiblemente necesarios para
-montar la imagen del sistema y algunos scripts para ponerlo en marcha.
-
-_* *{Imagen del sistema}*: La imagen del sistema de ficheros raiz. Por lo
-general, se utiliza un sistema de ficheros comprimido SquashFS para reducir
-al mínimo el tamaño de la imagen de Debian Live. Hay que tener en cuenta que
-es de sólo lectura. Por lo tanto, durante el arranque del sistema Debian
-Live se utiliza un disco RAM y un mecanismo de «unión» que permite escribir
-ficheros en el sistema en funcionamiento. Sin embargo, todas las
-modificaciones se perderán al apagar el equipo a menos que se use de modo
-opcional la persistencia (ver {Persistencia}#persistence).
-
-_* *{Gestor de arranque}*: Una pequeña pieza de código diseñada para
-arrancar desde el medio de almacenamiento escogido, posiblemente mostrando
-un menú o un indicador de arranque para permitir la selección de
-opciones/configuración. Carga el kernel de Linux y su initrd para funcionar
-con un sistema de ficheros asociado. Se pueden usar soluciones diferentes,
-dependiendo del medio de almacenamiento de destino y el formato del sistema
-de ficheros que contenga los componentes mencionados anteriormente: isolinux
-para arrancar desde un CD o DVD en formato ISO9660, syslinux para arrancar
-desde el disco duro o unidad USB desde una partición VFAT, extlinux para
-formatos ext2/3/4 y particiones btrfs, pxelinux para arranque de red PXE,
-GRUB para particiones ext2/3/4 , etc.
-
-Se puede usar live-build para crear la imagen del sistema a partir de
-ciertas especificaciones, incluir un kernel de Linux, su initrd y un gestor
-de arranque para ponerlos en funcionamiento, todo ello en un formato que
-depende del medio de almacenamiento elegido (imagen ISO9660, imagen de
-disco, etc.)
-
-2~building-iso-hybrid Primeros pasos: creación de una imagen ISO híbrida
-
-Independientemente del tipo de imagen, cada vez se tendrá que realizar los
-mismos pasos básicos para construir una imagen. Como primer ejemplo ejecutar
-la siguiente secuencia de comandos live-build para crear una imagen ISO
-híbrida básica que contiene sólo el sistema estándar de Debian sin X.org. Es
-adecuada para grabarla en un CD o DVD y también para copiarla en un
-dispositivo USB.
-
-En primer lugar, se ejecuta el comando #{lb config}#. Esto creará una
-jerarquía «config/» en el directorio actual que será usada por otros
-comandos:
-
-code{
-
- $ lb config
-
-}code
-
-Al no pasar ningún parámetro a #{lb config}#, se indica que se quiere
-utilizar todas las opciones por defecto. Ver{El comando lb config}#lb-config
-para más detalles.
-
-Ahora que existe un jerarquía «config/», se puede crear la imagen con el
-comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-Este proceso puede llevar un tiempo, dependiendo de la velocidad de la
-conexión de red. Cuando haya terminado, debería haber un fichero
-#{binary-hybrid.iso}# listo para ser usado en el directorio actual.
-
-2~using-iso-hybrid Usar una imagen ISO híbrida
-
-Después de construir o descargar una imagen ISO híbrida, las cuales se
-pueden obtener en http://www.debian.org/CD/live/, el siguiente paso
-habitual es preparar los medios de almacenamieto, ya sean medios ópticos
-CD-R(W) o DVD-R(W) o llaves USB.
-
-3~burning-iso-image Grabar una imagen ISO en un medio físico.
-
-Grabar una imagen ISO es fácil. Simplemente instalar wodim y usarlo desde el
-intérprete de comandos para grabar la imagen. Por ejemplo:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copiar una imagen ISO híbrida a un dispositivo
-USB
-
-Las imágenes ISO preparadas con el comando #{isohybrid}# igual que las
-imágenes del tipo #{iso-hybrid}# producidas por defecto, pueden
-sencillamente copiarse a una llave USB con #{dd}# o con un programa
-equivalente. Conectar una llave USB con un tamaño suficiente para la imagen
-y determinar qué dispositivo es, («device» N. del T.) al cual nos
-referiremos de ahora en adelante como #{${USBSTICK}}#. Este nombre de
-«dispositivo» se refiere a la llave entera como por ejemplo #{/dev/sdb}# y
-¡No a una partición como #{/dev/sdb1}#! Se puede encontrar el nombre del
-dispositivo correcto mirando la salida de #{dmesg}# después de conectar la
-llave, o mejor aún ejecutando #{ls -l /dev/disk/by-id}#.
-
-Cuando se esté seguro de tener el nombre del dispositivo correcto, usar el
-comando #{dd}# para copiar la imagen a la llave. *{¡Esto borrará de forma
-definitiva cualquier contenido previo en la llave!}*
-
-code{
-
-$ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Arrancar los medios en vivo
-
-La primera vez que se arranque desde los medios de almacenamiento en vivo,
-ya sea CD, DVD, llave USB, o de arranque en red PXE, primero puede ser
-necesario algún tipo de configuración en la BIOS de la máquina. Dado que las
-BIOS varían mucho en sus características y combinaciones de teclas, no se
-puede entrar en el tema en profundidad aquí. Algunas BIOS proporcionan una
-tecla para abrir un menú de dispositivos de arranque que es la manera más
-fácil de hacerlo si se encuentra disponible en el sistema.
-
-Una vez que se haya arrancado desde los medios de almacenamiento externos,
-se accede a un menú de arranque. Si se pulsa la tecla «enter», el sistema
-arrancará usando el modo por defecto #{Live}# y las opciones
-predeterminadas. Para obtener más información acerca de las opciones de
-arranque, ver la opción «help» del menú y también las páginas del manual de
-#{live-boot}# y #{live-config}# que se encuentran en el sistema en vivo.
-
-Suponiendo que se ha seleccionado #{Live}# y arrancado una imagen en vivo
-por defecto con escritorio gráfico, después de que los mensajes de arranque
-hayan pasado, se habrá iniciado automáticamente una sesión como usuario
-#{user}# y se verá el escritorio preparado para ser usado. Si se ha
-arrancado una imagen sólo con consola como por ejemplo las imágenes
-predeterminadas #{standard}# o #{rescue}# se habrá iniciado automáticamente
-una sesión como usuario #{user}# y se verá el cursor del intérprete de
-comandos preparado para ser usado.
-
-2~using-virtual-machine Usar una máquina virtual para pruebas
-
-Ejecutar las imágenes en vivo en una máquina virtual (VM) puede ser un gran
-ahorro de tiempo para su desarrollo. Esto no está exento de advertencias:
-
-_* Para ejecutar una máquina virtual se requiere tener suficiente memoria
-RAM para el sistema operativo huésped y el anfitrión y se recomienda una CPU
-con soporte de hardware para la virtualización.
-
-_* Existen algunas limitaciones inherentes a la ejecución en una máquina
-virtual, por ejemplo, rendimiento de video pobre, la limitada gama de
-hardware emulado.
-
-_* Cuando se desarrolla para un hardware específico, no hay sustituto mejor
-que el propio hardware.
-
-_* A veces hay errores que se refieren únicamente a la ejecución en una
-máquina virtual. En caso de duda, probar la imagen directamente en el
-hardware.
-
-Siempre que se pueda trabajar dentro de estas limitaciones, mirar que
-software VM hay disponible y elegir uno que sea adecuado según las
-necesidades.
-
-3~testing-iso-with-qemu Probar una imagen ISO con QEMU
-
-La máquina virtual más versátil en Debian es QEMU. Si el procesador tiene
-soporte de hardware para virtualización, utilizar el paquete #{qemu-kvm}# en
-la descripción del paquete #{qemu-kvm}# se enumera brevemente la lista de
-requisitos.
-
-En primer lugar, instalar #{qemu-kvm}# si el procesador lo soporta. Si no es
-así, instalar #{qemu}#, en cuyo caso el nombre del programa será #{qemu}# en
-vez de #{kvm}# en los siguientes ejemplos. El paquete #{qemu-utils}# también
-es útil para la creación de imágenes virtuales de disco con #{qemu-img}#.
-
-code{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Arrancar una imagen ISO es sencillo:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-Consultar las páginas del manual para más detalles.
-
-3~testing-iso-with-virtualbox Probar una imagen ISO con virtualbox-ose
-
-Para probar una imagen ISO con #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Crear una nueva máquina virtual, cambiar la configuración de almacenamiento
-para utilizar #{binary-hybrid.iso}# como dispositivo CD/DVD y arrancar la
-máquina.
-
-Nota: Para probar los sistemas en vivo con soporte X.org en virtualbox-ose,
-se puede incluir el paquete del driver de VirtualBox X.org,
-#{virtualbox-ose-guest-x11}#, en la configuración de live-build. De lo
-contrario, la resolución se limita a 800x600
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Crear una imagen USB/HDD
-
-La siguiente secuencia de comandos creará una imagen USB/HDD básica que
-contendrá sólo el sistema estándar de Debian sin X.org. Es adecuada para el
-arranque desde dispositivos USB, discos duros USB y otros dispositivos de
-almacenamiento portátil. Normalmente, se puede utilizar para este propósito
-una imagen ISO híbrida, pero es posible que la BIOS no maneje adecuadamente
-las imágenes híbridas. También es interesante una imagen USB/HDD si se desea
-utilizar el espacio restante en los medios de almacenamiento para una
-partición con persistencia.
-
-Nota: si se ha creado una imagen ISO híbrida con el ejemplo anterior, se
-tendrá que limpiar el directorio de trabajo con el comando #{lb clean}# (ver
-{El comando lb clean}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Ejecutar el comando #{lb config}# como antes pero esta vez especificando el
-tipo de imagen USB/HDD:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Crear ahora la imagen con el comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-Cuando termine el proceso de creación, debe haber un fichero llamado
-#{binary.img}# en el directorio actual .
-
-2~using-usb-hdd-image Utilizar una imágen USB/HDD
-
-La imagen binaria generada contiene una partición VFAT y el gestor de
-arranque syslinux, lista para ser copiada directamente en un dispositivo
-USB. Dado que utilizar una imagen USB/HDD es igual a usar una imagen ISO
-híbrida en un USB, seguir las instrucciones de {Usar una imagen ISO
-híbrida}#using-iso-hybrid con la diferencia de usar el nombre #{binary.img}#
-en lugar de #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Probar una imágen USB/HDD con Qemu
-
-En primer lugar, instalar QEMU como se describe más arriba en {Probar una
-imágen ISO con QEMU}#testing-iso-with-qemu A continuación, ejecutar #{kvm}#
-o #{qemu}#, según qué versión necesita el sistema anfitrión y especificando
-#{binary.img}# como primer disco duro.
-
-code{
-
- $ kvm -hda binary.img
-
-}code
-
-3~using-usb-extra-space Usar el espacio libre en el dispositivo USB
-
-Si se desea usar el espacio libre después de haber instalado la imagen
-#{binary.img}# en una llave USB, se puede usar un programa de particionado
-como #{gparted}# o #{parted}# para crear una partición nueva en el
-dispositivo. La primera partición será usada por el sistema Debian en vivo.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-Después de crear la partición, dónde #{${PARTITION}}# es el nombre de la
-partición, por ejemplo #{/dev/sdb2}# se tiene que crear un sistema de
-ficheros en él. Una opción posible sería ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Nota: Si se desea usar el espacio extra con Windows, segun parece, ese
-sistema operativo no puede acceder normalmente a otra partición más que a la
-primera. Se han comentado algunas soluciones a este problema en nuestra
-{lista de correo}#contact pero según parece no hay una solución fácil.
-
-*{Recordar: Cada vez que se instale una nueva binary.img en el dispositivo, todos los datos del dispositivo se perderán debido a que la tabla de particiones se sobrescribe con el contenido de la imagen, así pues, realizar primero una copia de seguridad de la partición para poder restaurarla trás actualizar la imagen en vivo.}*
-
-2~building-netboot-image Creación de una imagen de arranque en red
-
-La siguiente secuencia de comandos creará una imagen de arranque en red
-básica que contendrá el sistema estándar de Debian sin X.org. Se puede usar
-para el arranque en red.
-
-Nota: si se ha seguido algúno de los ejemplos anteriores, se tendrá que
-limpiar el directorio de trabajo con el comando #{lb clean}#:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Ejecutar el comando #{lb config}# de la siguiente manera para configurar la
-imagen de arranque en red:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-A diferencia de las imágenes ISO y USB/HDD, el sistema de arranque en red en
-sí mismo no envía la imagen del sistema de ficheros al cliente, por eso los
-ficheros se deben enviar mediante NFS. Las opciones #{--net-root-path}# y
-#{--net-root-server}# especifican la ubicación y el servidor,
-respectivamente, del servidor NFS en el que se encuentra la imagen del
-sistema de ficheros en el arranque. Se debe asegurar que estos se ajustan a
-los valores adecuados para la red y el servidor deseados.
-
-Crear ahora la imagen con el comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-En un arranque en red, el cliente ejecuta una pequeña pieza de software que
-generalmente se encuentra en la EPROM de la tarjeta Ethernet. Este programa
-envía una solicitud de DHCP para obtener una dirección IP e información
-sobre qué hacer a continuación. Por lo general, el siguiente paso es
-conseguir un gestor de arranque de alto nivel a través del protocolo
-TFTP. Este gestor podría ser PXELINUX, GRUB, o incluso arrancar directamente
-un sistema operativo como Linux.
-
-Por ejemplo, si se descomprime el archivo generado #{binary-net.tar.gz}# en
-el directorio #{/srv/debian-live}#, se verá la imagen del sistema de
-ficheros en #{live/filesystem.squashfs}# y el kernel, initrd y el gestor de
-arranque pxelinux en #{tftpboot/debian-live/i386}#.
-
-Ahora se debe configurar tres servicios en el servidor para que arranque en
-red: el servidor DHCP, el servidor TFTP y el servidor NFS.
-
-3~ Servidor DHCP
-
-Hay que configurar el servidor DHCP de red para asegurar que proporciona una
-dirección IP al cliente, y para anunciar la ubicación del gestor de arranque
-PXE.
-
-He aquí un ejemplo que puede servir de inspiración. Fue escrito para el
-servidor ISC DHCP #{isc-dhcp-server}# en su fichero de configuración
-#{/etc/dhcp/dhcpd.conf}#:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - fichero de configuración para isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ Servidor TFTP
-
-Se encarga de suministrar el kernel y el Disco RAM inicial para el sistema.
-
-Se debe instalar el paquete tftpd-hpa. Este servidor podrá suministrar todos
-los ficheros contenidos de un directorio raíz, normalmente
-#{/srv/tftp}#. Para permitirle que pueda servir los ficheros de
-#{/srv/debian-live/tftpboot}#, se debe ejecutar el siguiente comando con
-privilegios de superusuario:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-y llenar el directorio del nuevo servidor tftp cuando sea requerido.
-
-3~ Servidor NFS
-
-Una vez el equipo cliente ha descargado y arrancado el kernel de Linux junto
-a su initrd, intentará montar el sistema de archivos de la imagen en vivo a
-través de un servidor NFS.
-
-Se debe instalar el paquete #{nfs-kernel-server}#.
-
-Entonces, se debe hacer que la imagen del sistema de archivos esté
-disponible a través de NFS añadiendo una línea como la siguiente para
-#{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-e informar al servidor NFS sobre esta nueva exportación con el siguiente
-comando:
-
-code{
-
- # exportfs -rv
-
-}code
-
-La configuración de estos tres servicios puede ser un poco difícil. Será
-necesario un poco de paciencia para conseguir que todos ellos funcionen
-juntos. Para obtener más información, ver el wiki de syslinux en
-http://syslinux.zytor.com/wiki/index.php/PXELINUX o la sección sobre TFTP
-Net Booting del Manual del Instalador de Debian en
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html Esto puede ser
-útil, ya que sus procesos son muy similares.
-
-3~ Cómo probar el arranque en red
-
-La creación de una imagen de arranque en red es fácil usando la mágia de
-live-build, pero probar las imágenes en máquinas físicas puede ser un
-proceso mucho más lento.
-
-Para hacer nuestra vida más fácil, se puede utilizar la virtualización. Hay
-dos soluciones.
-
-3~ Qemu
-
-_* Install #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Se debe editar el fichero #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Obtener o crear un #{grub-floppy-netboot}# (en el svn).
-
-Lanzar #{qemu}# con "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Instalar VMWare Player (Edición gratuita «free as in beer»)
-
-_* Crear un directorio PXETester y crear un fichero de texto dentro llamado
-#{pxe.vwx}#
-
-_* Copiar este texto dentro:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* Se pueden realizar pruebas con este fichero de configuración
-(p.ej. cambiar el limite de memoria a 256)
-
-_* Hacer doble clic en este fichero (o lanzar VMWare player y seleccionar
-este fichero).
-
-_* Mientras esté en ejecución, si surge esa extraña pregunta, simplemente
-hay que pulsar «espacio» ...
diff --git a/manual/es/user_customization-binary.ssi b/manual/es/user_customization-binary.ssi
deleted file mode 100644
index 1189837..0000000
--- a/manual/es/user_customization-binary.ssi
+++ /dev/null
@@ -1,38 +0,0 @@
-B~ Personalización de la imagen binaria
-
-1~customizing-binary Personalización de la imagen binaria
-
-2~ Gestor de arranque
-
-live-build utiliza syslinux como gestor de arranque por defecto, el cual
-está configurado de forma predeterminada para hacer una pausa indefinida en
-su pantalla de bienvenida. Para modificar esto, se puede pasar
-#{--syslinux-timeout TIMEOUT}# a #{lb config}#. El valor se especifica en
-segundos. Un tiempo de espera de 0 (cero) desactiva el tiempo de espera por
-completo. Para obtener más información, consultar syslinux (1).
-
-2~ Metadatos ISO
-
-Al crear una imagen binaria ISO9660 se pueden utilizar las siguientes
-opciones para añadir varios metadatos textuales a la imagen. Esto puede
-ayudar a identificar fácilmente la versión o la configuración de una imagen
-sin arrancarla.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: Esto debería especificar
-la aplicación que estará en la imagen. La longitud máxima para este campo es
-de 128 caracteres.
-
-_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: Esto debería identificar quién
-prepara la imagen, por lo general con algunos detalles de contacto. El valor
-predeterminado para esta opción es la versión de live-build que se está
-utilizando, lo que puede ayudar con la posterior depuración de errores. La
-longitud máxima para este campo es de 128 caracteres.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: Esto debería identificar quién
-publica la imagen, por lo general con algunos detalles de contacto. La
-longitud máxima para este campo es de 128 caracteres.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: Esto debería especificar el volumen
-de identificación de la imagen. Esto se utiliza como etiqueta visible para
-el usuario en algunas plataformas como Windows y Apple Mac OS. La longitud
-máxima para este campo es de 32 caracteres.
diff --git a/manual/es/user_customization-contents.ssi b/manual/es/user_customization-contents.ssi
deleted file mode 100644
index 12aedef..0000000
--- a/manual/es/user_customization-contents.ssi
+++ /dev/null
@@ -1,181 +0,0 @@
-:B~ Personalización de contenidos
-
-1~customizing-contents Personalización de contenidos
-
-Este capítulo trata, no solamente de una mera descripción de cómo
-seleccionar los paquetes a incluir en el sistema en vivo, sino que además
-presenta cómo hacer el «ajuste fino» de la personalización de los contenidos
-del propio sistema. Los «añadidos» (includes) permiten adjuntar o reemplazar
-cualquier fichero en la imagen Debian Live a crear, los scripts gancho
-(hooks) permiten ejecutar cualquier orden en las diferentes etapas de
-creación y en el momento del arranque y por último, la preconfiguración
-permite configurar paquetes cuando son instalados, suministrando las
-respuestas a las preguntas de debconf.
-
-2~ Includes
-
-Idealmente, un sistema Debain Live debería incluir solamente ficheros que
-son obtenidos de paquetes Debian no modificados. Sin embargo, algunas veces
-es conveniente incluir o modificar algún contenido mediante ficheros. La
-utilización de «añadidos» (includes) posibilita la inclusión, modificación o
-cambio de cualquier fichero en la imagen Debian Live a crear. live-build
-tiene tres mecanismos:
-
-_* Includes locales en chroot : Estos includes permiten incluir o reemplazar
-ficheros del entorno chroot. Para más información ver {Includes locales en
-Live/chroot}#live-chroot-local-includes
-
-_* Includes locales en Binary: Estos includes permiten incluir o reemplazar
-ficheros en la propia imagen binaria generada. Para más información ver
-{Includes locales en Binary}#binary-local-includes
-
-_* Includes en Binary: Estos includes permiten incluir o reemplazar ficheros
-específicos de Debian en la imagen binaria, como pueden ser plantillas o
-directorios de herramientas. Para más información ver {Includes en
-Binary}#binary-includes
-
-Para más infomación acerca de la diferencia entre las imágenes "Live" y
-"binary" ver {Términos}#terms
-
-3~live-chroot-local-includes Includes locales en Live/chroot
-
-Los includes locales en chroot se utilizan para incluir o reemplazar
-ficheros en el sistema de ficheros Live/chroot de manera que puedan ser
-utilizados en el sistema en vivo. Una utilización típica de estos Includes
-puede ser el rellenar el directorio (#{/etc/skel}#) del sistema en vivo para
-que sea utilizado en la creación del directorio home al dar de alta usuarios
-en el sistema en vivo. Otra utilización típica es suministrar ficheros de
-configuración que puedan ser incluidos o reemplazados en la imagen sin
-necesidad de realizar proceso alguno (Los ficheros son simplemente copiados
-sin realizar ningún proceso de los mismos para adecuarlos al sistema
-concreto. N. del T); Si se necesita realizar algún procesado de estos
-ficheros ver la sección {Scripts gancho locales en
-Live/chroot}#live-chroot-local-hooks
-
-Para incluir ficheros solamente hace falta añadirlos al directorio de
-configuración #{config/chroot_local-includes}#. Habrá una relación directa
-entre este directorio y el directorio raiz (#{/}#) del sistema en vivo. Por
-ejemplo, si se desea añadir un fichero para que sea el fichero
-#{/var/www/index.html}# del sistema en vivo se puede hacer lo siguiente:
-
-code{
-
-$ mkdir -p config/chroot_local-includes/var/www
-$ cp /donde/esté/el/fichero/original/index.html config/chroot_local-includes/var/www
-
-}code
-
-El directorio de configuración presentará la siguiente jerarquía:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Los includes locales en chroot serán instalados después de la instalación de
-los paquetes de manera que los includes sobreescribirán cualquier fichero
-que los paquetes puedan haber instalado.
-
-3~binary-local-includes Includes locales en Binary
-
-Se puede incluir material como documentación, videos, etc en el sistema de
-ficheros del medio de instalación (USB, CDROM, etc) donde se grabará la
-imagen de manera que sea accesible nada más insertar el medio sin necesidad
-de arrancar el sistema en vivo. Para esto se utilizan los includes locales
-en Binary. Funciona de manera similar a los includes locales en chroot
-comentados anteriormente. Por ejemplo, supongamos que en el medio de
-instalación se desea añadir unos ficheros con videos de demostración sobre
-el funcionamiento del sistema en vivo de manera que el usuario pueda acceder
-a ellos a través de la página de indice HTML. Simplemente se debe copiar el
-material en #{config/binary_local-includes/}# de la siguiente manera:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-Los ficheros aparecerán en el directorio raiz del medio desde el que se
-instalará el sistema en vivo.
-
-3~binary-includes Includes en Binary
-
-live-build tiene algún fichero estandar, como puede ser la documentación,
-que se incluyen por defecto en el medio de instalación. Esto puede ser
-desactivado con:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-Si no se utiliza esta opción, live-build instalará el material en el
-directorio #{/includes/}# del sistema de ficheros del medio de instalación
-por defecto. En lugar de none, se puede especificar un directorio
-alternativo mediante la misma opción #{--includes}#.
-
-2~ Scripts gancho (Hooks)
-
-Los scripts gancho permiten ejecutar órdenes para personalizar la imagen en
-las etapas chroot y binary.
-
-3~live-chroot-local-hooks Scripts gancho locales en Live/chroot
-
-Para ejecutar órdenes en la etapa chroot se deben crear scripts gancho que
-contengan dichas ordenes a ejecutar y depositarlos en el directorio
-#{config/chroot_local-hooks}#. Estos scripts serán ejecutados en el entorno
-del chroot después de que el resto de las tareas de preparación del chroot
-han sido realizadas. Se debe asegurar que previamente se han instalado en el
-entorno chroot cualquier paquete, fichero u órden que necesiten los scripts
-gancho. El paquete live-build instala en el directorio
-#{/usr/share/live/build/examples/hooks}# del sistema huésped unos cuantos
-scripts gancho para realizar tareas habituales de personalización del
-entorno chroot que pueden ser copiados o referenciados mediante enlace
-simbólico en el directorio de configuración #{config/chroot_local-hooks}#.
-
-3~boot-time-hooks Scripts gancho en tiempo de arranque
-
-Para ejecutar ordenes en el arranque del sistema en vivo, se puede
-suministrar scripts gancho a live-config depositándolos en el directorio
-#{config/chroot_local-includes/lib/live/config/}#, tal y como se explica en
-la sección de "Personalización" de la página de manual de live-config. Es
-interesante examinar los scripts gancho que trae de serie live-config que
-pueden verse en #{/lib/live/config/}# y fijarse en la secuencia de
-números. Cuando se vaya a utilizar scripts propios deben ser prefijados con
-un número para indicar el orden de ejecución. Otra posibilidad es utilizar
-un paquete personalizado tal y como se describe en {Instalar paquetes de
-terceros o paquetes
-modificados}#installing-modified-or-third-party-packages.
-
-3~ Scripts gancho locales en Binary
-
-Para ejecutar comandos en la etapa Binary se deben crear scripts gancho que
-contengan las ordenes y depositarlos en el directorio
-#{config/binary_local-hooks}#. Los scripts gancho se ejecutarán después de
-finalizar el resto de procesos de la etapa pero antes de crear los checksum
-con binary_checksum que es el último proceso que se ejecuta en esta
-etapa. Los scripts gancho no se ejecutan en el entorno del chroot, así que
-hay que tener cuidado de no modificar cualquier fichero fuera del árbol de
-creación, o se dañará el sistema de creación. En
-#{/usr/share/live/build/examples/hooks}# se pueden ver varios ejemplos de
-scripts gancho genéricos que permiten tareas de personalización para la
-etapa Binary. Estos scripts pueden ser utilizados copiandolos o creando
-enlaces simbólicos en #{config/binary_local-hooks}#.
-
-2~ Preconfiguración de las preguntas de Debconf
-
-Los ficheros del directorio #{config/chroot_local-preseed}# son ficheros de
-preconfiguración para debconf. live-build instalará estos ficheros mediante
-#{debconf-set-selections}#.
-
-Ver debconf(7) en el paquete #{debconf}# para obtener más información acerca
-de debconf.
diff --git a/manual/es/user_customization-installer.ssi b/manual/es/user_customization-installer.ssi
deleted file mode 100644
index ab5b459..0000000
--- a/manual/es/user_customization-installer.ssi
+++ /dev/null
@@ -1,94 +0,0 @@
-:B~ Personalización del Instalador de Debian
-
-1~customizing-installer Personalización del Instalador de Debian
-
-Las imágenes de sistemas Debian Live pueden integrarse con el Instalador de
-Debian. Hay varios tipos de instalación que se diferencian en qué se incluye
-en la imágen y en cómo opera el instalador.
-
-En esta sección se debe estar atento a la utilización de las
-mayúsculas. Cuando se utiliza «Instalador de Debian», con mayúsculas, se
-hace referencia explícita al instalador oficial del sistema Debian, y a nada
-más ni a ningún otro instalador. A menudo se abrevia con «d-i».
-
-2~ Tipos de imágenes según el instalador
-
-Principalmente existen tres tipos de imágenes según el instalador:
-
-*{Imágenes con Instalador Debian «official»}*: Esta imagen de Debian Live se puede considerar como la imagen habitual. Dispone de un kernel y un initrd diferenciados que, al ser seleccionados desde el gestor de arranque, ejecuta un Instalador de Debian estándar, de la misma manera que lo haría si se arrancase desde una imagen de CD descargada desde el sitio oficial de Debian. Las imágenes que contienen un sistema en vivo con otro instalador independiente se suelen llamar «imágenes combinadas».
-
-En estas imágenes, el sistema operativo Debian se instala mediante la
-herramienta #{debootstrap}# o #{cdebootstrap}# que descarga paquetes .deb,
-desde medios locales o por red local, y los instala de forma tradicional. El
-resultado final es un sistema Debian estándar instalado en el disco duro.
-
-El conjunto de este proceso puede ser preconfigurado (preseeded) y
-personalizado de muchas maneras; Para más información, ver las páginas
-relevantes en el manual del Instalador de Debian. Una vez que se ha generado
-el fichero de preconfiguración adecuado a las necesidades, live-build puede
-encargarse de depositarlo en la imagen y activarlo de forma automática.
-
-*{Imágenes con Instalador Debian «Live»}*: Estas imágenes de Debian Live también disponen de un kernel y un initrd diferenciados que, al ser seleccionados desde el gestor de arranque, ejecutan un Instalador de Debian algo diferente.
-
-El procedimiento de instalación es idéntico al realizado por las imagenes
-«Regulares» pero, en lugar de utilizar #{debootstrap}# para obtener e
-instalar paquetes .deb, lo que hace es copiar al disco duro la imagen del
-sistema de ficheros que se había preparado para lanzar el sistema en
-vivo. Esto se logra mediante un .udeb especial llamado live-installer.
-
-Una vez finalizada esta etapa, el Instalador de Debian continua normalmente,
-instalando y configurando los siguientes elementos como pueden ser gestor de
-arranque, creación de usuarios locales, etc.
-
-Nota: Para poder arrancar los dos tipos de imágenes, Regular y Live, en el
-mismo medio, el gestor de arranque debe poder deshabilitar
-live-installer. Esto se hace utilizando la variable de preconfiguración
-(preseed) #{live-installer/enable=false}#.
-
-*{Instalador Debian «del escritorio»}*: Una vez el sistema en vivo está ejecutandose, se puede lanzar el Instalador de Debian haciendo clic en el icono correspondiente, sin importar el tipo de Instalador Debian utilizado en el arranque. Esta manera de instalar Debian es más sencilla para el usuario y aconsejable en algunas situaciones. Para poder realizar esta acción se debe instalar el paquete debian-installer-launcher.
-
-Por defecto, live-build no incluye las imágenes que utilizan el Instalador
-de Debian. Esto debe ser habilitado de forma específica en #{lb
-config}#. También hay que hacer notar que, para que la instalación desde «el
-escritorio» funcione, el kernel del sistema en vivo debe ser el mismo que el
-kernel que utiliza #{d-i}# en la arquitectura especificada. Por ejemplo:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Personalizando el Instalador de Debian mediante preconfiguración
-
-Tal y como se describe en el apéndice B del manual del Instalador de Debian
-que puede consultarse en
-http://www.debian.org/releases/stable/i386/apb.html, «La preconfiguración
-permite asociar respuestas a preguntas que aparecen en el proceso de
-instalación, sin tener que responderlas manualmente en el momento se se
-ejecuta dicho proceso. Esto hace posible automatizar totalmente la mayoria
-de las instalaciones e incluso ofrece alguna característica que no está
-disponible durante una instalación normal.» Con live-build se puede llevar
-a cabo esta personalización depositando un fichero llamado #{preseed.cfg}#
-en el directorio de configuración #{config/binary_debian-installer/}#. Por
-ejemplo, para preconfigurar la variante local a #{es_ES}# se puede hacer:
-
-code{
-
- $ echo "d-i debian-installer/locale string es_ES" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Personalizar el contenido del Instalador de Debian
-
-Es posible que, con propósitos experimentales o para depuración, se desee
-incluir paquetes udeb creados localmente. Estos paquetes udeb son
-componentes del Instalador de Debian que definen su comportamiento. Para
-incluirlos en la imagen, basta con depositarlos en el directorio de
-configuración #{config/binary_local-udebs/}#. También pueden incluirse o
-reemplazarse ficheros y directorios en el initrd del instalador de una
-manera similar a la que se describe en {Includes locales en
-Live/chroot}#live-chroot-local-includes, depositando el material en el
-directorio #{config/binary_debian-installer-includes/}#.
diff --git a/manual/es/user_customization-overview.ssi b/manual/es/user_customization-overview.ssi
deleted file mode 100644
index 3975cc4..0000000
--- a/manual/es/user_customization-overview.ssi
+++ /dev/null
@@ -1,93 +0,0 @@
-:B~ Personalización de contenidos
-
-1~customization-overview Descripción general de la personalización.
-
-Este capítulo presenta un resumen de las diversas formas en que se puede
-personalizar un sistema Debian Live.
-
-2~ Configuración en el momento de la creación vs en el momento del arranque
-
-Las opciones de configuración de un sistema Debian Live se pueden dividir en
-opciones que se aplican en el momento de la creación de la imágen del
-sistema en vivo y opciones que se tendrán en cuenta cuando el sistema en
-vivo arranque. Estas últimas se puenden dividir a su vez en opciones que se
-tienen en cuenta en una etapa inicial del arranque, utilizadas por el
-paquete live-boot, y otras que se aplicarán posteriormente y que son
-utilizadas por el paquete live-config. Cualquier opción en tiempo de arraque
-puede ser modificada por el usuario indicándola en los parámetros de
-arranque del kernel mediante el indicador de arranque (boot prompt). La
-imagen puede ser creada por defecto con los parámetros de arranque
-adecuados, de manera que los usuarios solamente tendrán que arrancar el
-sistema en vivo, directamente, sin necesidad de especificar ninguna opción
-adicional, ya que las opciones por defecto serán las adecuadas. En
-particular, la opcion #{lb --bootappend-live}# permite introducir cualquier
-parámetro del kernel para el sistema en vivo, como pueden ser la
-persistencia, distribución del teclado, zonas horarias, etc. Ver un ejemplo
-en {Personalización de las variantes locales e
-idioma}#customizing-locale-and-language.
-
-Las opciones de configuración en tiempo de creación se describen en la
-página del manual del comando #{lb config}#. Las opciones en tiempo de
-arranque se describen en las páginas de manual de los paquetes live-boot y
-live-config. Aunque los paquetes live-boot y live-config se instalan en el
-sistema en vivo que se está creando, también se recomienda que sean
-instalados en el sistema huésped, que se utiliza para crear la imagen del
-sistema en vivo, con el fin de facilitar la referencia cuando se trabaja en
-una configuración. No hay ningún problema en hacerlo, ya que ninguno de los
-scripts que contiene el sistema huésped será ejecutado, a menos que se
-configure el sistema huésped como sistema en vivo, cosa que no tiene
-sentido.
-
-2~stages-of-the-build Etapas de la creación
-
-El proceso de creación de la imagen está dividido en etapas en las que se
-aplican diferentes personalizaciones en cada una de ellas. La primera etapa
-que se ejecuta es la etapa *{bootstrap}*. Esta fase inicial crea y rellena
-el directorio chroot con paquetes que constituyen un sistema Debian
-básico. A continuación la etapa *{chroot}* completa la creación del
-directorio chroot, rellenándolo con todos los paquetes que han sido listados
-en la configuración y material adicional. En esta etapa se utiliza la
-mayoría de las personalizaciones de contenido. La etapa *{binary}* es la
-etapa final en la que se prepara la imagen del sistema en vivo utilizando el
-contenido del directorio chroot para construir el sistema de ficheros raiz
-del futuro sistema en vivo, se incluye el instalador y cualquier otro
-material adicional de la imagen que no es parte el sistema de fichero raiz,
-como puede ser el gestor de arranque (bootloader) o ficheros de
-documentación. Posteriormente, en la etapa opcional *{source}* se creará el
-fichero comprimido (tarball) que contiene los ficheros de código fuente de
-los paquetes utilizados.
-
-En cada una de estas etapas hay una secuencia particular en la se aplican
-las acciones a realizar. Estas acciones son organizadas en forma de capas de
-tal manera que aseguran la personalización de una manera razonable. Por
-ejemplo, dentro de la etapa *{chroot}*, las preconfiguraciones (preseeds) se
-aplican antes que cualquier paquete sea instalado, los paquetes son
-instalados antes de incluir ningún fichero localmente o antes de aplicar
-cualquer parche y los scripts gancho (hooks) serán ejecutados al final de
-todo, una vez que todos los materiales están ubicados en su lugar.
-
-2~ Opciones para lb config en ficheros
-
-Aunque la orden #{lb config}# crea un esqueleto de configuración en el
-directorio config/, quizás sea necesario escribir ficheros de configuración
-adicionales dentro de la jerarquía de subdirectorios de config/ con el fin
-de alcanzar los objetivos propuestos. En el proceso de creación de la imagen
-estos ficheros adicionales serán copiados o en el sistema de ficheros que se
-utilizará en el sistema en vivo, o en el sistema de ficheros de la propia
-imagen binaria o quizás podrán suministrar opciones de configuracion al
-sistema en vivo que sería incomodo pasar en la línea de parámetros del
-kernel. Esto dependerá de en qué parte de la jerarquía de subdirectorios de
-config/ se copian estos ficheros. Se puede incluir cosas como listas de
-paquetes personalizadas, imágenes gráficas personalizadas o scripts gancho
-(hook scripts) para ejecutar o en el momento de creación de la imagen o en
-el momento de arranque del sistema en vivo, aumentando la ya por otra parte
-considerable, flexibilidad de Debian Live con código creado ex profeso.
-
-2~ Tareas de personalización
-
-Los siguientes capítulos se organizan por tareas de personalización que el
-usuario realiza típicamente: Los capítulos de {Personalización de la
-instalación de paquetes}#customizing-package-installation, {Personalización
-de contenidos}#customizing-contents y {Personalización de las variantes
-locales e idioma}#customizing-locale-and-language cubre solamente unas pocas
-de las tareas que pueden realizarse.
diff --git a/manual/es/user_customization-packages.ssi b/manual/es/user_customization-packages.ssi
deleted file mode 100644
index f35c435..0000000
--- a/manual/es/user_customization-packages.ssi
+++ /dev/null
@@ -1,644 +0,0 @@
-:B~ Personalización de la instalación de paquetes
-
-1~customizing-package-installation Personalización de la instalación de
-paquetes
-
-Quizás la tarea más básica de personalización en Debian Live es la selección
-de paquetes que serán incluidos en la imagen. Este capítulo orienta a través
-de las diferentes opciones de live-build que, en el momento de la creación
-de la imagen, personalizan la instalación de paquetes. Las opciones que
-seleccionan la distribucion base y las áreas del archivo Debian a utilizar
-son las que más influyen a la hora de conocer qué paquetes estarán
-disponibles para su instalación en la imagen. Para asegurar una buena
-velocidad de descarga de paquetes, se debería elegir el repositorio Debian
-más cercano. Se pueden añadir repositorios para paquetes backports,
-experimentales, paquetes personalizados o incluir ficheros de paquetes
-directamente. Se pueden definir listas de paquetes a incluir personalizadas,
-utilizar listas predefinidas en live-build, seleccionar tareas de
-#{tasksel}# o una combinación de los tres métodos. Por último existen varias
-opciones que dan algún control sobre cuando son instalados los paquetes por
-la herramienta apt o la herramienta aptitude, según sea la elegida. Estas
-opciones pueden ser útiles si se utiliza un proxy, se quiere desactivar la
-instalación de paquetes recomendados para ahorrar espacio o se necesita
-controlar las versiones de los paquetes a instalar mediante APT pinning, por
-nombrar algunas posibilidades.
-
-2~ Origen de los paquetes
-
-3~ Distribución, áreas de archivo y modo
-
-La distribución seleccionada tiene gran impacto en qué paquetes están
-disponibles para incluir en la imagen. Se debe indicar el nombre en clave de
-la distribución, que por defecto es #{squeeze}# para la versión Squeeze de
-live-build. Se puede especificar cualquier nombre de distribución disponible
-en los repositorios Debian indicando su nombre en clave. (Para más detalles
-ver {Términos}#terms). La opción #{--distribution}# no solamente influencia
-la fuente de los paquetes dentro del archivo Debian, sino que instruye a
-#{live-build}# a comportarse tal y como se necesita para construir cada una
-de las distribuciones. Por ejemplo, para construir contra la versión
-*inestable*, Sid, se debe indicar:
-
-code{
-
- $ lb config --distribution sid
-
-}code
-
-Las áreas del archivo Debian son la principal división de paquetes dentro de
-una distribución dada. En Debian las áreas del archivo establecidas son
-#{main}#, #{contrib}# y #{non-free}#. Solamente los paquetes contenidos en
-#{main}# son parte de la distribución Debian. Ésta es el área definida por
-defecto en live-build. Se pueden indicar uno o más valores tal y como se
-muestra en el siguiente ejemplo:
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Experimentalmente hay soporte para alguna distribución derivada de Debian
-mediante la opción #{--mode}#. Por defecto, esta opción toma el valor de
-#{debian}# incluso si live-build se está ejecutando en un sistema no
-Debian. Si se especifica #{--mode ubuntu}# o #{--mode emdebian}# se
-utilizará el nombre de la distribución y las áreas de archivos específicas
-de la distribución derivada en lugar de los propios de Debian y live-build
-modificará su comportamiento para adecuarlo al modo seleccionado.
-
-*{Nota:}* La ayuda a los usuarios de las distribuciones para las cuales se añadieron estos modos son responsabilidad de los desarrolladores de dichas distribuciones. El proyecto Debian Live proporciona ayuda al desarrollo de la mejor manera posible, basándose en la información recogida de dichas distribuciones derivadas a pesar de que no desarrolla ni da soporte a las mismas.
-
-3~ Réplicas de Distribución Debian
-
-Los repositorios de Debian están replicados en una gran red alrededor del
-mundo, de manera que se puede seleccionar la réplica más cercana con el fin
-de obtener la mejor velocidad de descarga. Cada una de las opciones
-#{--mirror-*}# gobierna qué réplica de repositorio Debian se utiliza en las
-diferentes etapas de creación. Si se recuerda de {Etapas de la
-creación}#stages-of-the-build, en la etapa de *preinstalación (bootstrap)*
-es cuando se crea el directorio chroot y se rellena con un sistema mínimo
-mediante la herramienta debootstrap, y en la etapa *chroot* es cuando el
-directorio chroot es completado con los paquetes necesarios para crear el
-sistema de ficheros que será utilizado en el sistema en vivo. A cada una de
-estas etapas le corresponde su propia opción #{--mirror-*}#. Posteriormente,
-en la etapa *binary* se utilizarán las réplicas Debian indicadas en los
-valores de las opciones #{--mirror-binary}# y #{--mirror-binary-security}#
-en lugar de utilizar los indicados para las etapas anteriores.
-
-3~distribution-mirrors-build-time Réplicas de Distribution utilizadas
-durante la creación
-
-Para indicar qué réplicas deben ser utilizadas en el momento de crear la
-imágen es suficiente con utilizar las opciones #{--mirror-bootstrap}# y
-#{--mirror-chroot-security}# como se muestra a continuación.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-El valor indicado en #{--mirror-chroot}# es utilizado como valor por defecto
-para la opción #{--mirror-bootstrap}# si esta no es indicada.
-
-3~ Réplicas de distribución Debian utilizadas en la ejecución.
-
-Las opciones #{--mirror-binary*}# gobiernan las réplicas configuradas en la
-imagen binaria que serán utilizadas para instalar paquetes adicionales
-mientras se ejecuta el sistema en vivo. Por defecto se utiliza
-#{cdn.debian.net}#, que es un servicio que selecciona la réplica más cercana
-basándose en el número de IP. Es una elección bastante acertada siempre que
-no se pueda predecir que réplica será la mejor para todos los
-usuarios. También se puede especificar valores personalizados como se
-muestra en el siguiente ejemplo. Una imágen construida con esta
-configuración solamente sería accesible a los usuarios de una red donde
-"#{mirror}#" fuese alcanzable.
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Repositorios adicionales
-
-Se pueden añadir más repositorios, ampliando la lista de paquetes
-seleccionables más alla de aquellos disponibles para la distribución
-indicada, como pueden ser paquetes de backports, paquetes experimentales o
-personalizados. Para configurar repositorios adicionales se debe crear los
-ficheros #{config/chroot_sources/your-repository.chroot}#, y/o
-#{config/chroot_sources/your-repository.binary}#. Al igual que en las
-opciones #{--mirror-*}#, estos ficheros gobiernan los repositorios
-utilizados en las etapas *chroot* y *binary* respectivamente, esto es, los
-repositorios que serán utilizados cuando se ejecute el sistema en vivo.
-
-Por ejemplo, #{config/chroot_sources/live.chroot}# permite instalar paquetes
-de la instantánea del repositorio Debian Live en el momento de crear la
-imagen.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-Si se añade la misma línea a #{config/chroot_sources/live.binary}#, el
-repositorio será añadido al directorio #{/etc/apt/sources.list.d/}# del
-sistema en vivo.
-
-Estos ficheros serán seleccionados automáticamente si existen.
-
-Se debería también incluir en el fichero
-#{config/chroot_sources/your-repository.{binary,chroot}.gpg}# la clave GPG a
-utilizar para firmar dicho repositorio.
-
-*{Nota:}* Existen algunos repositorios de paquetes ya preconfigurados para facilitar la selección mediante la opción #{--repository}#. Por ejemplo, para utilizar las instantáneas del repositorio de Debian Live, sería suficiente con activarlo mediante:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Selección de los paquetes a instalar
-
-Hay varias maneras de seleccionar qué paquetes serán instalados por
-live-build en la imagen que cubren una variedad de necesidades diversas. Se
-puede nombrar un paquete individual para que sea instalado o se pueden
-nombrar unos pocos paquetes mediante la opción #{--packages}#, o incluso se
-puede indicar un gran número de paquetes mediante una lista. También se
-puede seleccionar listas de paquetes predefinidos o incluso utilizar tareas
-de APT. Por último, también se pueden utilizar ficheros de paquetes de
-prueba o experimentales obtenidos antes de que aparezcan en los repositorios
-oficiales simplemente depositando estos ficheros directamente en el árbol de
-directorios #{config/}#.
-
-3~ Selección de unos pocos paquetes
-
-Cuando el número de paquetes a añadir es pequeño pueden indicarse mediante
-la opción #{--packages}#. Por ejemplo:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-El comportamiento de live-build cuando se especifica un paquete que no
-existe es determinado por lo que se haya configurado en la utilidad
-APT. Para más detalles ver {Utilizar apt o
-aptitude}#choosing-apt-or-aptitude .
-
-Si se necesita especificar un gran número de paquetes o se necesita cierta
-flexibilidad a la hora de indicar qué paquetes hay que instalar se puede
-utilizar las listas de paquetes tal y como se indica en la sección, {Listas
-de paquetes}#package-lists.
-
-3~package-lists Listas de paquetes
-
-Las listas de paquetes proporcionan una potente forma de expresar qué
-paquetes deberían ser instalados. La sintaxis de la lista soporta la
-inclusión de ficheros y secciones condicionales, que facilitan la creación
-de listas a partir de otras listas, adaptando su utilización a diversas
-configuraciones. También pueden utilizarse listas de paquetes predefinidas,
-dando una manera modular a la selección de paquetes para cada uno de los
-diferentes entornos de escritorios y algunas listas de propósito especial
-basadas en otras listas de propósito general. Puede utilizarse listas
-propias o una combinación de listas propias y listas predefinidas.
-
-3~ Listas de paquetes predefinidas
-
-La forma más simple de utilizar listas de paquetes es especificar una o más
-listas predefinidas mediante la opción #{--packages-lists}#, por ejemplo:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-Además de estas listas, live-build soporta cuatro listas de paquetes
-virtuales, #{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# y
-#{xfce-desktop}#, cada una de las cuales provee una selección de paquetes
-extensiva que corresponde con los valores por defecto del Instalador de
-Debian para estos entornos de escritorio. Para más información ver {Tareas
-de Escritorio e Idioma}#desktop-and-language-tasks .
-
-*{Nota:}* Existen imágenes listas para su descarga con los escritorios GNOME, KDE, LXDE y XFCE en http://live.debian.net. Estas imágenes han sido creadas utilizando la lista virtual #{*-desktop}# correspondiente.
-
-La ubicación por defecto de las listas de los ficheros en el sistema huésped
-es #{/usr/share/live/build/lists/}#. Para determinar qué paquetes componen
-una lista dada se debe leer el correspondiente fichero poniendo atención en
-los ficheros incluidos y en las secciones condicionales como se describen a
-continuación.
-
-3~ Listas de paquetes locales
-
-Se pueden añadir o reemplazar completamente las listas predefinidas
-depositando listas de paquetes locales en el directorio
-#{config/chroot_local-packageslists/}#.
-
-Para que sean procesadas, las listas de paquetes que existan en dicho
-directorio deben tener la extensión #{.list}#. Las listas de paquetes
-locales se superponen a las listas predefinidas por live-build. Esto puede
-causar efectos no deseados de manera que se recomienda utilizar nombres
-únicos para las listas de paquetes locales, que no coincidan con los nombres
-de listas de paquetes predefinidas.
-
-3~ Listas de paquetes locales para binary
-
-En caso de que se desee incluir algún paquete .deb en el directorio
-#{pool/}# del medio de instalación sin instalarlo en la imágen del sistema
-en vivo se pueden utilizar las listas de paquetes locales para binary
-depositando dichas listas en el directoro
-#{config/binary_local-packageslists/}#, de manera que el medio de
-instalación pueda ser utilizado como un medio de instalación personalizado
-para instalaciones sin red local (modo offline).
-
-Para que sean procesadas, las listas de paquetes que se depositen en este
-directorio deben tener la extensión #{.list}#.
-
-3~ Extensión de una lista de paquetes dada mediante «includes»
-
-Las listas de paquetes predefinidas en live-build hacen un uso intensivo de
-las directivas «include». Los ficheros existentes en el directorio
-#{/usr/share/live/build/lists/}# pueden servir como buen ejemplo de como
-escribir listas de paquetes.
-
-Por ejemplo, para hacer una lista de paquetes que incluya la lista de
-paquetes predefinida #{gnome}# y añadir el paquete iceweasel se puede crear
-un fichero llamado #{config/chroot_local-packageslists/mygnome.list}# con el
-siguiente contenido:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Utilización de condiciones dentro de las listas de paquetes
-
-En las sentencias condicionales de las listas de paquetes pueden utilizarse
-cualquier variable disponible en #{config/*}# (excepto las que tienen el
-prefijo #{LB_}#). En general esto significa que puede utilizarse cualquier
-opción válida para #{lb config}# cambiando las letras minúsculas por
-mayúsculas y los guiones por subrayados. En la práctica solamente tiene
-sentido utilizar aquellas variables relacionadas con la selección de
-paquetes, como pueden ser #{DISTRIBUTION}#, #{ARCHITECTURE}# o
-#{ARCHIVE_AREAS}#.
-
-Por ejemplo, para instalar el paquete #{ia32-libs}# si se ha especificado la
-arquitectura amd64 (#{--architecture amd64}#) se puede utilizar:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-En la expresión condicional pueden utilizarse varios valores. Por ejemplo
-para instalar el paquete #{memtest86+}# si la arquitectura es i386
-(#{--architecture i386}#) o es amd64 (#{--architecture amd64}#) se puede
-especificar:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-En la expresión condicional también pueden utilizarse variables que pueden
-contener más de un valor. Por ejemplo para instalar #{vrms}# si se utilizan
-las áreas del archivo #{contrib}# o #{non-free}# mediante la opción
-#{--archive-areas}# se puede indicar:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-Es habitual que una condición incluya una directiva «include»:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-No se permite el anidamiento de estructuras condicionales.
-
-3~ Tareas
-
-El Instalador de Debian ofrece al usuario un conjunto de opciones con una
-lista de paquetes preseleccionada enfocadas a configurar un tipo de sistema
-o configurar el sistema para realizar una tarea como puede ser «Entorno de
-escritorio gráfico», «Servidor de correo», «Portátil», etc. Estas listas son
-llamadas «tareas» y son soportadas por APT mediante el campo «Task:». Se
-puede especificar a live-build que seleccione estas tareas mediante la
-opción #{--task}# tal y como se muestra en el siguiente ejemplo:
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-Una vez ha sido arrancado el sistema en vivo puede conocerse qué tareas
-primarias están disponibles en el Instalador de Debian mediante la orden
-#{tasksel --list-tasks}#. La lista de paquetes contenidos en cualquier tarea
-(incluidas aquellas que no aparecen en la lista de tareas primarias) puede
-obtenerse mediante la orden #{tasksel --task-packages}#.
-
-3~desktop-and-language-tasks Tareas de Escritorio e Idioma
-
-Las tareas de escritorio y de idioma son casos especiales. Si el medio de
-instalación fue preparado para una clase particular de entorno de
-escritorio, el Instalador de Debian instalará automáticamente la tarea de
-entorno de escritorio correspondiente. Para ello existen las tareas
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# y #{xfce-desktop}# pero
-ninguna de ellas son presentadas en el menú de #{tasksel}#. De igual forma,
-las tareas para idiomas tampoco son presentadas en el menú de #{tasksel}#,
-pero la selección del idioma, al inicio de la instalación repercute en la
-selección de las correspondientes tareas del idioma.
-
-En live-build estos casos especiales también son tratados de manera
-especial, pero en el momento de escribir este manual, hay tres notables
-diferencias.
-
-Primero, no se ha previsto, todavía, la instalación automática de tareas de
-idiomas, aunque se incluye un subconjunto de estos paquetes si se especifica
-un idioma mediante #{lb config --language}#. Se puede especificar en la
-configuración de live-build la utilización de estas tareas, que incluyen
-cosas específicas del idioma, como pueden ser paquetes tipos de letra y
-métodos de introducción. Por ejemplo:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-Segundo, live-build soporta la lista de paquetes virtuales #{*-desktop}#
-para cada clase de escritorio mencionado anteriormente. Esto seleccionará la
-lista de paquetes predefinida #{standard-x11}#, la correspondiente tarea de
-escritorio #{*-desktop}# y tres tareas adicionales #{desktop}#,
-#{standard}# y #{laptop}#. Así, por ejemplo, si se especifica
-#{--packages-lists gnome-desktop}#, será equivalente a especificar
-#{--packages debian-installer-launcher --packages-lists standard-x11 --tasks
-"gnome-desktop desktop standard laptop"}#.
-
-Tercero, si se selecciona cualquier tarea de escritorio, explícitamente a
-través de #{--tasks}# o implícitamente mediante #{--packages-lists}#,
-live-build preconfigurará (preseed) en el Instalador de Debian (si es
-incluido) el escritorio correspondiente para asegurar que sigue sus propias
-reglas cuando sea instalado.
-
-*{Nota:}* Existe también la opción experimental #{--language}# cuyo propósito se solapa con las tareas de idioma. Se instalarán los paquetes de soporte #{*-l10n}# siempre que existan y que se especifique un idioma mediante la opción #{--language}#. Además, si existe, se utilizará, en lugar de las plantillas por defecto en ingles, cualquier plantilla para #{syslinux}# del idioma indicado mediante esta opción. La selección de paquetes realizada mediante la opción #{--language}# es una pobre aproximación a las tareas de idiomas. Las tareas de idiomas son un método más completo y flexible que la utilización de la opción #{--language}# que requiere que la lista de paquetes a incluir por idioma sea mantenida internamente en live-build. Sin embargo el tratamiento de las plantillas de #{syslinux}# es útil. Por esto, si se utiliza la opción #{--bootloader syslinux}# y plantillas para un idioma existente en #{/usr/share/live/build/templates/syslinux/}# o #{config/temp
lates/syslinux/}#, esta opción es un punto a tener en cuenta, posiblemente en combinación con las tareas de idiomas para asegurar la instalación de los paquetes adecuados. Por ejemplo:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Esta opción solamente soporta un idioma y un gestor de arranque. Por todas
-estas razones, el futuro de esta opción está bajo revisión y posiblemente
-será reemplazada por algo completamente diferente en la proxima revisión
-general de live-build.
-
-2~installing-modified-or-third-party-packages Instalar paquetes de terceros
-o paquetes modificados
-
-Si bien está en contra de la filosofía de Debian Live, en ocasiones es
-necesario crear un sistema en vivo con versiones de paquetes modificados a
-partir de los disponibles en el repositorio de Debian. Estos paquetes pueden
-modificar características existentes o dar soporte a características
-adicionales, idiomas y derivados (branding), o eliminar elementos existentes
-en los paquetes que no son de interes. De manera similar, se pueden incluir
-paquetes «de terceros» para añadir funcionalidades a medida o propietarias.
-
-En esta sección no se describe la creación o mantenimiento de paquetes
-personalizados. Puede ser interesante una lectura del método descrito por
-Joachim Breitner 'How to fork privately' en
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html.
-La guía del nuevo desarrollador de Debian en
-http://www.debian.org/doc/maint-guide/ describe la creación de paquetes a
-medida.
-
-Existen dos formas de instalar paquetes personalizados:
-
-_* #{chroot_local-packages}#
-
-_* Utilizando un repositorio APT personalizado
-
-El método #{chroot_local-packages}# es el más simple para añadir paquetes
-personalizados. Es muy útil para personalizaciones «rápidas» (one-off) pero
-tiene unos cuantos inconvenientes mientras que la utilización de un
-repositorio APT personalizado es más lento de poner en marcha.
-
-3~ Método #{chroot_local-packages}# para instalar paquetes personalizados
-
-Para instalar paquetes personalizados solamente hay que copiar el paquete en
-el directorio #{config/chroot_local-packages/}#. Los paquetes contenidos en
-este directorio serán automáticamente instalados en el sistema en vivo
-durante el proceso de creación. No es necesario especificar de dónde se
-deben obtener los paquetes.
-
-Los paquetes *{deben}* nombrarse de la forma prescrita. La forma más simple
-es usar #{dpkg-name}#.
-
-El método #{chroot_local-packages}# para la instalación de paquetes
-personalizados tiene desventajas:
-
-_* No es posible utilizar APT seguro.
-
-_* Se deben depositar todos los paquetes necesarios para cumplir
-dependencias en el directorio #{config/chroot_local-packages/}#.
-
-_* No es adecuado para almacenar configuraciones de Debian Live en un
-control de versiones.
-
-3~ Método de repositorio APT para instalar paquetes personalizados
-
-Al contrario del método #{chroot_local-packages}#, cuando se utiliza el
-método de repositorio APT personalizado se debe asegurar que se especifica
-dónde se deben buscar los paquetes a instalar. Para más información ver
-{Selección de los paquetes a instalar}#choosing-packages-to-install.
-
-Aunque crear un repositorio APT para instalar paquetes personalizados puede
-parecer un esfuerzo innecesaro, la infraestructurar puede ser fácilmente
-reutilizada posteriormente para ofrecer nuevas versiones de los paquetes.
-
-3~ Paquetes personalizados y APT
-
-live-build utiliza APT para instalar todos los paquetes en el sistema en
-vivo, así que hereda sus comportamientos. Un punto a resaltar es que
-(asumiendo una configuración de APT por defecto) dado un paquete en dos
-repositorios diferentes con diferentes números de versiones, APT
-seleccionará para instalar el paquete con número de versión superior.
-
-Esta sería una buena razón para incrementar el número de version en los
-ficheros #{debian/changelog}# de los paquetes personalizados y así asegurar
-que serán estos los paquetes instalados en lugar de los contenidos en los
-repositorios oficiales de Debian. Esto puede también lograrse alterando las
-preferencias de pinning de APT del sistema en vivo. Para más información ver
-{APT pinning}#apt-pinning.
-
-2~ Configurar APT en la creación
-
-Se puede configurar APT mediante varias opciones que se aplicarán en el
-momento de crear la imagen. (La configuración que APT utilizará cuando se
-ejecute el sistema en vivo puede ser configurada de la manera que
-habitualmente se utiliza para introducir contenidos del sistema en vivo,
-esto es, incluyendo las configuraciones apropiadas en el directorio
-#{config/chroot_local_includes/}#.) Se puede encontrar una lista completa de
-las opciones para configurar APT en la página de manual de
-#{lb_config}#. Son aquellas opciones que comienzan con #{apt}#.
-
-3~choosing-apt-or-aptitude Utilizar apt o aptitude
-
-Se puede seleccionar qué herramienta se utilizará para instalar paquetes,
-#{apt}# o #{aptitude}#, en el momento de crear la imagen mediante la opción
-#{--apt}# de #{lb config}#. Esta selección definirá el comportamiento
-preferido en la instalación de paquetes, siendo la mayor diferencia la
-manera de tratar los paquetes no disponibles.
-
-_* #{apt}#: Con este método, si se especifica un paquete no existente, la
-instalación fallará. Es el comportamiento por defecto.
-
-_* #{aptitude}#: Con este método, si se especifica un paquete no existente,
-la instalación continuará sin error.
-
-3~ Utilización de un proxy con APT
-
-Un problema habitual en la configuración de APT es tratar con la creación de
-una imagen desde detras de un proxy. Se puede especificar dicho proxy con
-las opciones #{--apt-ftp-proxy}# o #{--apt-http-proxy}#. Por ejemplo:
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Ajuste de APT para ahorrar espacio
-
-En ocasiones será necesario ahorrar algún espacio en el medio de
-instalación. Las dos opciones descritas a continuación pueden ser de
-interes.
-
-Si no se desea incluir los índices de APT en la imagen creada se puede
-utilizar la siguiente opción:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-Esto no modificará el comportamiento de las entradas definidas en
-/etc/apt/sources.list, sino que solo afecta a si exitirán o no ficheros de
-índice en el directorio /var/lib/apt. El compromiso viene de que APT
-necesita estos ficheros índices para funcionar en el sistema en vivo, así
-que, si no existen, el usuario deberá ejecutar la orden #{apt-get update}#
-para crear estos índices antes de poder ejecutar una orden del tipo
-#{apt-cache search}# o #{apt-get install}#.
-
-Si la instalación de los paquetes recomendados aumenta demasiado el tamaño
-de la imagen, se puede desactivar el valor por defecto de esta opción de APT
-con:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-Lo que está en juego aqui es que, si no se instalan los paquetes
-recomendados para un paquete dado, esto es «los paquetes que supuestamente
-deberían encontrase intalados si un paquete ya lo está» (Debian Policy
-Manual, seccion 7.2), algún paquete que supuestamente debería estar
-instalado será omitido. Por otra parte, se sugiere que, si se desactiva esta
-opción, se revise las recomendaciones hechas a la lista de paquetes indicada
-(ver el fichero #{binary.packages}# generado por #{lb build}#) y que se
-incluya en la lista cualquier paquete que deba ser instalado. Si se
-encuentra que el número de paquetes descartado es pequeño, se recomienda que
-la opción se active y que se utilice una prioridad negativa para el pin de
-APT en dichos paquetes y así evitar que sean instalados tal y como se
-explica en {APT pinning}#apt-pinning.
-
-3~ Pasar opciones a apt o a aptitude
-
-Si no existe ninguna opción de #{lb config}# para alterar el comportamiento
-de APT tal y como se desea, se puede utilizar las opciones #{--apt-options}#
-o #{--aptitude-options}# para pasar cualquier opción que se desee a la
-herramienta APT. Para más información, ver las páginas de manual de #{apt}#
-y #{aptitude}#.
-
-3~apt-pinning APT pinning
-
-Como información básica, sería recomendable leer la página de manual
-#{apt_preferences(5)}#. APT pinning puede ser configurado o en tiempo de
-creación de la imagen, creando el fichero #{config/chroot_apt/preferences}#
-o en tiempo de ejecución del sistema en vivo creando el fichero
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Supongamos que se está creando un sistema en vivo basado en Squeeze pero se
-necesita instalar todos los paquetes "live" que terminan instalados en la
-imagen binaria final desde la versión inestable «Sid» en el momento de crear
-la imagen. Se deberá añadir Sid a los orígenes (sources) de APT y fijarlo
-(pin) de manera que solamente los paquetes fijados sean instalados desde Sid
-mientras que el resto será obtenido desde la distribución base,
-Squeeze. Esto se puede realizar de la siguiente forma:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Nota:}* Se pueden usar comodines en los nombres de los paquetes a fijar (p.ej. *{Package: live-*}*) si se usa una versión de apt igual o superior a 0.8.14. Esto significa que funciona con Wheezy usando:
-
-code{
-
-$ lb config --distribution wheezy
-
-}code
-
-Una prioridad pin negativa previene la instalación de un paquete, como puede
-ser el caso de que no se desee que un paquete recomendado por otro sea
-instalado al instalar el primero. Supongamos que se está creando una imagen
-LXDE mediante la opción #{--packages-lists lxde}#, pero no se desea
-preguntar al usuario si desea almacenar las claves wifi en el almacen de
-claves. La lista lxde incluye #{gdm}#, la cual depende de #{gksu}# que a su
-vez recomienda #{gnome-keyring}#. Así que el objetivo es omitir la
-instalación del paquete #{gnome-keyring}#, que puede conseguirse añadiendo
-un fichero con el siguiente contenido a #{config/chroot_apt/preferences}#:
-
-code{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/es/user_customization-runtime.ssi b/manual/es/user_customization-runtime.ssi
deleted file mode 100644
index 7c1c9a5..0000000
--- a/manual/es/user_customization-runtime.ssi
+++ /dev/null
@@ -1,256 +0,0 @@
-:B~ Personalización del comportamiento en tiempo de ejecución.
-
-1~customizing-run-time-behaviours Personalización del comportamiento en
-tiempo de ejecución.
-
-Toda la configuración que se hace en tiempo de ejecución es realizada por
-live-config. Éstas son algunas de las opciones más comunes de live-config en
-las que los usuarios están más interesados. Se puede encontrar una lista
-completa de todas las posibilidades en la página del manual de live-config.
-
-2~ Personalización del usuario por defecto del sistema en vivo
-
-Una consideración importante es que el usuario por defecto del sistema en
-vivo es creado por live-boot en el arranque y no live-build durante la
-creación de la imagen. Ésto no sólo influye dónde se introducen los
-materiales relacionados con este usuario durante la creación de la imagen
-tal y como se explica en {Includes locales en
-Live/chroot}#live-chroot-local-includes sino también a cualquier grupo y a
-los permisos asociados con el usuario por defecto del sistema en vivo.
-
-Se puede especificar grupos adicionales a los que pertenecerá el usuario por
-defecto del sistema en vivo preconfigurando el valor debconf
-#{passwd/user-default-groups}#. Por ejemplo, para agregar el usuario al
-grupo #{fuse}# añadir el siguiente código en un fichero en el directorio
-#{config/chroot_local-preseed}#.
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-Además, es posible cambiar el usuario por defecto "user" y la contraseña por
-defecto "live". Si se desea cambiarlos por cualquier motivo, se puede
-conseguir de forma sencilla tal y como se explica a continuación:
-
-Cambiar el nombre del usuario por defecto es tan sencillo como especificarlo
-en la configuración:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-Una posible forma de cambiar la contraseña por defecto es usando un script
-gancho (hook) tal y como se describe en {Scripts gancho en tiempo de
-arranque}#boot-time-hooks. Para conseguirlo se puede usar el script gancho
-«passwd» de #{/usr/share/doc/live-config/examples/hooks}#, ponerle un
-prefijo adecuado (p.ej. 200-passwd) y añadirlo a
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Personalización de las variantes locales e
-idioma
-
-Cuando el sistema en vivo arranca, el idioma está implicado en tres pasos:
-
-_* Generar las variantes locales
-
-_* Establecer la distribución del teclado para el consola
-
-_* Establecer la distribución del teclado para el entorno gráfico X
-
-La variante local predeterminada en la creación de un sistema en vivo es
-"locales=en_US.UTF-8". Para definir la variante local que se debe generar,
-se puede utilizar el parámetro #{locales}# en la opción
-#{--bootappend-live}# de #{lb config}#, p.ej.
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-Este parámetro también se puede utilizar en la línea de comandos del
-kernel. Se puede especificar una variante local usando una palabra completa
-#{language_country.encoding}#.
-
-Tanto la configuración del teclado de la consola y del entorno gráfico X
-dependen del parámetro #{keyboard-layouts}# de la opción
-#{--bootappend-live}#. Se pueden encontrar opciones válidas de la
-disposición del teclado en #{/usr/share/X11/xkb/rules/base.xml}# (bastante
-limitado a los códigos de país de dos letras). Para hallar el valor (los dos
-letras) que corresponde a un idioma se puede buscar el nombre en inglés de
-la nación donde se habla el idioma, por ejemplo:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-Por ejemplo, para obtener los ficheros de la variante local de la
-disposición del teclado alemán y suizo-alemán en X usar:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-Se puede ver una lista de los valores de teclados válidos para la consola
-con el siguiente comando:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-Alternativamente, se puede usar el paquete #{console-setup}# una herramienta
-que permite configurar la disposición de la consola utilizando definiciones
-X (XKB), a continuación, se puede configurar el teclado con mayor precisión
-con las variables #{keyboard-layouts}#, #{keyboard-variant}#,
-#{keyboard-options}# y #{keyboard-model}#; live-boot también usará estos
-parámetros para la configuración de X. Por ejemplo, para establecer un
-sistema francés con una distribución de teclas francés-Dvorak (llamado Bepo)
-en un teclado TypeMatrix, tanto en consola X como X11, se puede utilizar:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistencia (Modo guardar cambios)
-
-Un paradigma de un cd en vivo («live cd» N. del T.) es ser un sistema
-pre-instalado que funciona desde medios de almacenamiento de sólo lectura,
-como un CD-ROM, donde los cambios y las modificaciones no se guardan tras
-reiniciar el sistema en que se ejecuta.
-
-Un sistema Debian Live es una generalización de este paradigma pero que es
-compatible con otros medios de almacenamiento, no sólo en CDs. Aún así, en
-su comportamiento predeterminado, se debe considerar un sistema de sólo
-lectura y todos los cambios en tiempo de ejecución del sistema se pierden al
-apagar el equipo.
-
-La persistencia (o modo guardar cambios) es un nombre común que se dá a los
-diferentes tipos de soluciones para guardar algunos o todos los cambios
-realizados durante la ejecución tras reiniciar el sistema. Para entender
-cómo funciona es útil saber que incluso si el sistema se inicia y se ejecuta
-desde los medios de almacenamiento de sólo lectura, las modificaciones de
-los ficheros y directorios se escriben en medios de escritura, por lo
-general en la memoria ram (tmpfs) y los datos guardados en la ram no se
-guardan tras reiniciar.
-
-Los datos almacenados en esta memoria ram se pueden guardar en un soporte
-grabable como un disco duro, una memoria USB, un recurso compartido de red o
-incluso en una sesión de un CD/DVD regrabable en multisesión. Todos estos
-medios son compatibles con Debian Live de diferentes maneras, y todos menos
-el último requieren un parámetro de arranque especial que se especificará en
-el momento del arranque: #{persistent}#.
-
-3~ Persistencia total
-
-Por «Persistencia total» se entiende la utilización de una partición de
-escritura en lugar de usar un tmpfs (sistema de ficheros temporal) para
-guardar los cambios realizados a los medios de sólo lectura (con el sistema
-copiar-al-escribir o COW «copy-on-write» N. del T.). Para utilizar esta
-función se debe crear una partición grabable vacía con la etiqueta «live-rw»
-formateada con un sistema de ficheros compatible en el medio usado para
-arracar el sistema en vivo. En el momento de arrancar se debe iniciar el
-sistema con el parámetro de arranque 'persistent'. Esta partición puede ser
-una partición ext2 en el disco duro o en una memoria USB creada con, por
-ejemplo:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-Ver {Usar el espacio libre en el dispositivo USB}#using-usb-extra-space.
-
-Si ya existe una partición en el dispositivo, sólo se tiene que cambiar la
-etiqueta con uno de los siguientes:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-Pero ya que los usuarios de un sistema en vivo no siempre pueden utilizar
-una partición del disco duro, y teniendo en cuenta que la mayoría de
-memorias USB tienen velocidades de escritura lentas, la persistencia total
-también puede ser usada con ficheros imagen, de este modo se puede crear un
-fichero que represente una partición y poner ese fichero imagen incluso en
-una partición NTFS de un sistema operativo no nativo, con algo similar a
-esto:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-A continuación, copiar el fichero #{live-rw}# a un partición grabable y
-reiniciar el sistema con el parámetro de arranque «persistent».
-
-3~ Montar Home de forma automática
-
-Si durante el arranque se encuentra una partición (sistema de ficheros) con
-un fichero imagen o una partición con la etiqueta #{home-rw}# el sistema de
-ficheros será montado de forma automática como #{/home}#, lo que permite la
-persistencia de los ficheros que pertenecen a, por ejemplo, el usuario por
-defecto. Se puede combinar con persistencia total.
-
-3~ Instantáneas
-
-Las instantáneas son colecciones de ficheros y directorios que no se montan
-durante la ejecución, pero que se copian desde un dispositivo persistente al
-sistema (tmpfs) en el arranque y que se resincroniza en el reinicio/apagado
-del sistema. El contenido de una instantánea puede residir en una partición
-o en un fichero imagen (como los tipos mencionados anteriormente) con la
-etiqueta #{live-sn}#, pero el valor predeterminado es un archivo cpio simple
-denominado #{live-sn.cpio.gz}#. Como en el caso anterior, en el momento del
-arranque los dispositivos conectados al sistema se recorren buscando una
-partición o un fichero llamado así. Una interrupción de la alimentación en
-tiempo de ejecución podría conducir a la pérdida de datos, por lo tanto, se
-puede usar la herramienta #{live-snapshot --refresh}# para sincronizar
-cambios importantes. Este tipo de persistencia es la menos agresiva con
-dispositivos tipo flash y el más rápido de todos los sistemas de
-persistencia, ya que no escribe continuamente en los medios de
-almacenamiento.
-
-Existe también una versión de la instantánea /home y su etiqueta es
-#{home-sn.*}#; que funciona igual que la instantánea principal, pero sólo se
-aplica a /home.
-
-Las instantáneas actualmente no pueden manejar el borrado de ficheros pero
-la persistencia total y el montaje automático sí pueden.
-
-3~ SubText persistente
-
-Si un usuario necesita un almacenamiento persistente múltiple del mismo tipo
-para diferentes lugares o pruebas, tales como #{live-rw-nonwork}# y
-#{live-rw-work}#, el parámetro de arranque #{persistent-subtext}# usado
-junto con el parámetro de arranque #{persistent}# permitirá medios de
-almacenamiento persistentes múltiples pero únicos. Un ejemplo sería si un
-usuario desea utilizar una partición persistente etiquetada
-#{live-sn-subText}# usaría los parámetros de arranque de: #{persistent}#
-#{persistent-subtext=subText}#.
-
-3~ Remasterización parcial
-
-La modificación en tiempo de ejecución de la tmpfs podría ser guardada
-usando una instantánea en vivo en un squashfs y añadirla a un cd
-remasterizando la iso en el caso de un cd-r o añadiendo una sesión a un
-cd/dvd(rw) multisesión; live-boot monta todo el sistema de ficheros /live en
-orden o con el parámetro del módulo de arranque.
diff --git a/manual/es/user_examples.ssi b/manual/es/user_examples.ssi
deleted file mode 100644
index 7e0a153..0000000
--- a/manual/es/user_examples.ssi
+++ /dev/null
@@ -1,419 +0,0 @@
-:B~ Ejemplos
-
-1~examples Ejemplos
-
-Este capítulo ofrece ejemplos de creación de imágenes para casos de uso
-específicos de Debian Live. Si se es nuevo en la creación de una imagen
-propia de Debian Live, se recomienda mirar primero a los tres tutoriales en
-secuencia, ya que cada uno enseña nuevas técnicas que ayudan a utilizar y
-entender los ejemplos restantes.
-
-2~using-the-examples Uso de los ejemplos
-
-Para poder seguir estos ejemplos es necesario un sistema donde crearlos que
-cumpla con los requisitos enumerados en {Requisitos}#requirements y tener
-live-build instalado tal y como se describe en {Instalación de
-live-build}#installing-live-build.
-
-Hay que tener en cuenta que, para abreviar, en estos ejemplos no se
-especifica una réplica local para la creación de la imagen. Es posible
-acelerar las descargas considerablemente si se utiliza una réplica local. Se
-puede especificar las opciones cuando se usa #{lb config}#, tal y como se
-describe en {Réplicas de Distribution utilizadas durante la
-creación}#distribution-mirrors-build-time, o para más comodidad, establecer
-el valor por defecto para la creación del sistema en
-#{/etc/live/build.conf}#. Basta con crear este fichero y en el mismo,
-establecer las variables correspondientes a la réplica preferida. Por
-ejemplo:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: Una imagen estándar
-
-*{Caso práctico:}* Crear una primera imagen sencilla, aprendiendo los fundamentos de live-build.
-
-En este tutorial, vamos a construir una imagen ISO hybrid por defecto de
-Debian Live que contenga únicamente los paquetes base (sin Xorg) y algunos
-paquetes de soporte Debian Live, como un primer ejercicio en el uso de
-live-build.
-
-No puede ser más fácil que esto:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Si se examina el contenido del directorio #{config/}# se verá almacenada
-allí una configuración en esqueleto preparada para ser personalizada o en
-este caso para ser usada inmediatamente para construir una imagen por
-defecto.
-
-Ahora, como superusuario, crear la imagen, guardando un log con #{tee}#
-mientras se crea.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Suponiendo que todo va bien, después de un rato, el directorio actual
-contendrá #{binary-hybrid.iso}#. Esta imagen ISO híbrida se puede arrancar
-directamente en una máquina virtual como se describe en {Probar una imagen
-ISO con Qemu}#testing-iso-with-qemu y en {Probar una imagen ISO con
-virtualbox-ose}#testing-iso-with-virtualbox o bien ser copiada a un medio
-óptico como un dispositivo USB tal y como se describe en {Grabar una imagen
-ISO en un medio físico}#burning-iso-image y {Copiar una imagen ISO híbrida
-en un dispositivo USB}#copying-iso-hybrid-to-usb, respectivamente.
-
-2~tutorial-2 Tutorial 2: Una utilidad de navegador web
-
-*{Caso práctico:}* Crear una utilidad de navegador web, aprendiendo a aplicar personalizaciones.
-
-En este tutorial, se creará una imagen adecuada para su uso como utilidad de
-navegador web, esto sirve como introducción a la personalización de las
-imágenes de Debian Live.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-La elección de LXDE para este ejemplo refleja el deseo de ofrecer un entorno
-de escritorio mínimo, ya que el enfoque de la imagen es el uso individual
-que se tiene en mente, el navegador web. Se podría ir aún más lejos y
-ofrecer una configuración por defecto para el navegador web en
-#{config/chroot_local-includes/etc/iceweasel/profile/}#, o paquetes
-adicionales de soporte para la visualización de diversos tipos de contenido
-web, pero se deja esto como un ejercicio para el lector.
-
-Crear la imagen, de nuevo como superusuario, guardando un log como en el
-{Tutorial 1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-De nuevo, verificar que la imagen está bien y probarla igual que en el
-{Tutorial 1}#tutorial-1.
-
-2~tutorial-3 Tutorial 3: Una imagen personalizada
-
-*{Caso práctico:}* Crear un proyecto para conseguir una imagen personalizada, que contenga el software favorito para llevárselo en una memoria USB donde quiera que se vaya, y hacerlo evolucionar en revisiones sucesivas, tal y como vayan cambiando las necesidades y preferencias.
-
-Como nuestra imagen personalizada irá cambiando durante un número de
-revisiones, si se quiere ir siguiendo esos cambios, probar nuevas cosas de
-forma experimental y posiblemente volver atrás si no salen bien, se guardará
-la configuración en el popular sistema de control de versiones
-#{git}#. También se utilizarán las mejores prácticas de configuración
-automática a través de scripts #{auto}# como se describe en {Gestionar una
-configuración}#managing-a-configuration.
-
-3~ Primera revisión
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Editar #{auto/config}# del siguiente modo:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-En primer lugar con #{--architecture i386}# se asegura de que en nuestro
-sistema de creación #{amd64}# se crea una versión de 32-bits adecuada para
-ser usada en la mayoría de máquinas. En segundo lugar, se usa
-#{--linux-flavours 686}# porque no se espera usar esta imagen en sistemas
-mucho más viejos. En tercer lugar se elige la lista de paquetes #{lxde}#
-para proporcionar un escritorio mínimo. Y, por último, se añaden dos
-paquetes iniciales favoritos: #{iceweasel}# y #{xchat}#.
-
-Ahora, crear la imagen:
-
-code{
-
- # lb build
-
-}code
-
-Tener en cuenta que a diferencia de los dos primeros tutoriales, ya no se
-tiene que escribir #{2>&1 | tee binary.log}# ya que esto se incluye ahora en
-#{auto/build}#.
-
-Una vez que se ha probado la imagen (como en el {Tutorial 1}#tutorial-1) y
-se ha asegurado de que funciona, es el momento de iniciar el repositorio
-git, añadiendo sólo los scripts auto que se acaba de crear, y luego hacer el
-primer commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Segunda revisión
-
-En esta revisión, vamos a limpiar desde la primera creación, agregar el
-paquete #{vlc}# a nuestra configuración, crear de nuevo, probar y enviar los
-cambios al git («commit» N.del T.).
-
-El comando #{lb clean}# limpiará todos los ficheros generados en las
-primeras creaciones a excepción del caché, lo cual ahorra tener que volver a
-descargar de nuevo los paquetes. Esto asegura que el siguiente #{lb build}#
-vuelva a ejecutar todas las fases para regenerar los ficheros de nuestra
-nueva configuración.
-
-code{
-
- # lb clean
-
-}code
-
-Editar ahora #{auto/config}# para añadir el paquete #{vlc}#:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Crear de nuevo:
-
-code{
-
-# lb build
-
-}code
-
-Probar, y cuando se esté satisfecho, enviar la próxima revisión al git:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Por supuesto, es posible hacer cambios más complicados en la configuración,
-tal vez añadiendo ficheros en los subdirectorios de #{config/}#. Cuando se
-envian nuevas revisiones, hay que tener cuidado de no editar a mano o enviar
-los ficheros del nivel superior en #{config}# que contienen variables
-#{LB_*}# ya que estos son productos de creación también y son siempre
-limpiados por #{lb clean}# y recreados con #{lb config}# a través de sus
-respectivos scripts #{auto}#.
-
-Hemos llegado al final de nuestra serie de tutoriales. Si bien son posibles
-muchos más tipos de personalización, aunque sólo sea con las pocas
-características explicadas en estos sencillos ejemplos, se puede crear una
-variedad casi infinita de imágenes diferentes. Los ejemplos que quedan en
-esta sección abarcan varios casos de usos diferentes procedentes de las
-experiencias recogidas de los usuarios de Debian Live.
-
-2~ Un cliente VNC kiosk
-
-*{Caso Práctico:}* Crear una imagen con live-build para arrancar directamente un servidor VNC.
-
-Hacer un directorio de creación y crear una configuración en esqueleto según
-la lista estándar-x11, incluyendo #{gdm3}#, #{metacity}# y
-#{xtightvncviewer}#, desactivando los paquetes recomendados para conseguir
-un sistema mínimo:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Crear el directorio #{/etc/skel}# y poner un fichero #{.xsession}#
-personalizado para el usuario que por defecto ejecutará metacity e iniciará
-el xvncviewer, conectándo al puerto #{5901}# de un servidor en
-#{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Crear la imagen:
-
-code{
-
- # lb build
-
-}code
-
-Disfrutar.
-
-2~ Una imagen básica para un pendrive USB de 128M
-
-*{Caso Práctico:}* Crear una imagen estándar quitando algunos componentes para que quepa en un pendrive USB de 128M dejándo espacio libre para poder usarlo.
-
-Al optimizar una imagen para adaptarla al tamaño de algunos medios de
-almacenamiento, es necesario comprender el equilibrio que se está haciendo
-entre tamaño y funcionalidad. En este ejemplo, se recorta tanto sólo para
-dar cabida a material adicional dentro de un tamaño de 128M, pero sin hacer
-nada para destruir la integridad de los paquetes que contiene, tales como la
-depuración de las variantes locales a través del paquete #{localepurge}# u
-otro tipo de optimizaciones «intrusivas». Cabe destacar que no se debe usar
-#{--bootstrap-flavour minimal}# a menos de que realmente se sepa lo que se
-está haciendo, ya que al omitir paquetes de prioridad #{importante}# lo más
-probable es que se produzca un sistema roto.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Ahora, crear la imagen de forma habitual:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-En el sistema del autor, en el momento de escribir esto, la configuración
-anterior produjo una imagen de 78Mbytes. Esto se compara favorablemente en
-tamaño con la imagen de 166Mbytes producida por la configuración por defecto
-en el {Tutorial 1}#tutorial-1.
-
-El mayor ahorro de espacio aquí, en comparación con la creación de una
-imagen estándar en un sistema de arquitectura #{i386}# es seleccionar sólo
-la versión del kernel #{486}# en lugar de la de por defecto #{-k "486
-686"}#. Dejar fuera los índices de APT con #{--binary-indices false}#
-también ahorra una cantidad importante de espacio, la desventaja es que es
-necesario hacer un #{apt-get update}# antes de usar apt en el sistema en
-vivo. Elegir la lista del paquete #{minimal}# deja fuera el gran paquete de
-#{locales}# y sus utilidades asociadas. Dejando los paquetes recomendados
-con #{--apt-recommends false}# se ahorra un poco de espacio adicional a
-costa de omitir algunos paquetes que de otro modo podría esperarse que
-estuvieran alli, tal como #{firmware-linux-free}# que puede ser necesario
-para el soporte de cierto hardware. Las opciones restantes recortan pequeñas
-cantidades adicionales de espacio. Es necesario decidir si vale la pena la
-funcionalidad que se sacrifica con cada optimización.
-
-2~ Un escritorio KDE con variante local e instalador
-
-*{Caso práctico:}* Crear una imagen del escritorio KDE, con la variante local Portugués de Brasil con instalador incluido.
-
-Se desea crear una imagen iso-hybrid para la arquitectura i386 con un
-escritorio preferido, en este caso el KDE, que contiene todos los mismos
-paquetes que serían instalados por el programa de instalación estándar de
-Debian para KDE.
-
-El primer problema es descubrir los nombres de las tareas adecuadas. En la
-actualidad, live-build no puede ayudar en esto. Aunque podríamos tener
-suerte y encontrarlos a base de pruebas, hay una herramienta,
-#{grep-dctrl}#, para extraerlos de las descripciones de tareas en
-tasksel-data, para prepararlos, asegurarse de tener ambas cosas:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Ahora podemos buscar las tareas apropiadas, primero con:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-Con este comando, se descubre que la tarea se llama, sencillamente,
-brazilian-portuguese. Ahora para encontrar las tareas relacionas:
-
-code{
-
-$ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-Se usará la opción experimental #{--language}#, ya que live-build incluye
-#{syslinux}# para pt_BR (ver {Tareas de Escritorio e
-Idioma}#desktop-and-language-tasks para más detalles). Y en el momento del
-arranque se generarán las variantes locales pt_BR.UTF-8 y se seleccionará el
-diseño del teclado pt-latin1. Ahora se ponen todas las piezas juntas:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Tener en cuenta que se ha incluido el paquete #{debian-installer-launcher}#
-para lanzar el instalador desde el escritorio en vivo, y que también se ha
-especificado el kernel 486, ya que actualmente es necesario que el
-instalador y el kernel del sistema en vivo coincidan para que el lanzador
-funcione correctamente.
diff --git a/manual/es/user_installation.ssi b/manual/es/user_installation.ssi
deleted file mode 100644
index c31af7f..0000000
--- a/manual/es/user_installation.ssi
+++ /dev/null
@@ -1,182 +0,0 @@
-:B~ Instalación
-
-1~installation Instalación
-
-2~requirements Requisitos
-
-Para crear las imágenes de Debian Live son necesarios los siguientes
-requisitos:
-
-_* Acceso de superusuario (root)
-
-_* Una versión actualizada de live-build
-
-_* Un intérprete de comandos compatible con POSIX, como por ejemplo /{bash}/
-o /{dash}/.
-
-_* /{debootstrap}/ o /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Tener en cuenta que no es necesario el uso de Debian o una distribución
-derivada de Debian - live-build funcionará en casi cualquier distribución
-que cumpla con los requisitos anteriores.
-
-2~installing-live-build Instalación de live-build
-
-Se puede instalar live-build de varias maneras diferentes:
-
-_* Desde el repositorio Debian
-
-_* A partir del código fuente
-
-_* Desde «instantáneas»
-
-Si se usa Debian, el método recomendado es instalar live-build a través del
-repositorio de Debian.
-
-3~ Desde el repositorio Debian.
-
-Simplemente instalar live-build como cualquier otro paquete:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-o
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ A partir del código fuente
-
-live-build se desarrolla utilizando el sistema de control de versiones Git.
-En los sistemas basados en Debian se encuentra el paquete /{git}/. Para ver
-el último código, ejecutar:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-Se puede crear e instalar el paquete Debian ejecutando:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Si se desea, se podrá instalar cualquiera de los paquetes #{.deb}# recien
-creados con el procedimiento anterior, p.ej.
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-También se puede instalar live-build directamente en el sistema ejecutando:
-
-code{
-
- # make install
-
-}code
-
-y desinstalarlo con:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ A partir de «instantáneas»
-
-Si no se desea crear o instalar live-build a partir del código fuente, se
-puede usar instantáneas. Estas se generan automáticamente a partir de la
-última versión de Git y están disponibles en http://live.debian.net/debian/.
-
-2~ live-boot y live-config
-
-*{Nota:}* No es necesario instalar live-boot o live-config en el sistema para crear sistemas personalizados de Debian Live. Sin embargo, eso no causará ningún daño y es útil por motivos de referencia. Si únicamente se desea tener la documentación, es posible instalar los paquetes live-boot-doc y live-config-doc de forma independiente.
-
-3~ Desde el repositorio Debian.
-
-Tanto live-boot como live-config están disponibles en el repositorio Debian
-siguiendo la {Instalación de live-build}#installing-live-build.
-
-3~ A partir del código fuente
-
-Para utilizar el último código fuente a partir de git, se puede seguir el
-proceso siguiente. Asegurarse de estar familiarizado con los términos
-mencionados en {Términos}#terms.
-
-_* Comprobar el código fuente de live-boot y live-config
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Si se desea generar estos paquetes a partir del código fuente, se puede
-consultar las páginas del manual para más detalles sobre la personalización
-de live-boot y live-config.
-
-_* Creación de los paquetes .deb de live-boot y live-config
-
-Se debe crear ya sea en la distribución de destino o en un entorno chroot
-que contenga la plataforma de destino: es decir, si el objetivo es Squeeze
-entonces se debe crear usando Squeeze.
-
-Utilizar un programa creador personal como /{pbuilder}/ o /{sbuild}/ si se
-necesita crear #{live-boot}# para una distribución de destino diferente del
-sistema de creación. Por ejemplo, para las imágenes en vivo de Squeeze,
-crear #{live-boot}# en un entorno chroot. Si la distribución de destino
-coincide con la distribución actual, se puede crear directamente sobre el
-sistema de creación con #{dpkg-buildpackage}# (proporcionada por el paquete
-/{dpkg-dev}/ ):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Utilizar todos los ficheros .deb generados
-
-Como live-boot y live-config son instalados por el sistema live-build, la
-instalación de estos paquetes en el sistema anfitrión no es suficiente: Se
-deben tratar los archivos .deb generados exáctamente igual que cualquier
-otro paquete personalizado. Véase {Personalización de la instalación de
-paquetes}#customizing-package-installation para más información. Se debe
-prestar especial atención a los {Repositorios
-adicionales}#additional-repositories.
-
-3~ A partir de «instantáneas»
-
-Se puede dejar que live-build utilice automáticamente las últimas
-instantáneas de live-boot y live-config mediante la configuración de
-repósitorios de terceros en el directorio de configuración de
-live-build. Suponiendo que ya se haya creado un árbol de configuración en el
-directorio actual con #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/es/user_managing_a_configuration.ssi b/manual/es/user_managing_a_configuration.ssi
deleted file mode 100644
index c653864..0000000
--- a/manual/es/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,109 +0,0 @@
-:B~ Gestionar una configuración
-
-1~managing-a-configuration Gestionar una configuración
-
-Este capítulo explica como gestionar una configuración para crear un sistema
-en vivo desde el principio, pasando por sucesivas versiones tanto de la
-herramienta live-build como de la imagen del sistema en vivo propiamente
-dicha.
-
-2~ Utilización de auto para gestionar los cambios de la configuración
-
-La configuración necesaria para crear un sistema en vivo rara vez es
-perfecta a la primera. Lo normal es que se necesite realizar una serie de
-revisiones hasta que se obtenga algo satisfactorio. Sin embargo, las
-inconsistencias pueden transmitirse de una revisión de la configuración a
-otra si no se es lo suficientemente cuidadoso. El principal problema es que,
-una vez que una variable de la configuración tiene un valor asignado, este
-valor no es recalculado en revisiones posteriores de la configuración. Esto
-hace que, si una variable depende del valor de otra y esta segunda cambia de
-valor, el valor actual de la primera no se ve alterado, debido a que ya
-tenía el valor asignado de antemano.
-
-Por ejemplo, la primera vez que se asigna la distribución a utilizar, se
-asigna a muchas variables un valor por defecto para adecuarse a la
-distribución seleccionada. Sin embargo, si posteriormente se decide
-modificar la distribución, estas variables dependientes continuan reteniendo
-los valores antiguos que, por supuesto, no son los adecuados para la nueva
-distribución.
-
-Otro problema es que la ejecución de la orden #{lb config}# no se
-reejecutará correctamente si se realiza una actualización a una nueva
-versión de las herramientas live-build que modifique el nombre de alguna
-variable de configuración. Además solamente podrá ser descubierto mediante
-una revisión manual de los ficheros del directorio #{config/*}# que se
-deberán modificar para asignar las variables de configuración a un nuevo
-valor apropiado.
-
-Todo esto sería un terrible embrollo si no fuese por los scripts auto/*
-simples envoltorios para los comandos #{lb config}#, #{lb build}# y #{lb
-clean}# que están diseñados para ayudar a la gestión de la
-configuración. Simplemente se debe crear un script llamado auto/config que
-contenga el comando #{lb config}# con todas las opciones que se deseen y
-otro script llamado auto/clean que elimine los ficheros que contienen los
-valores de las variables de configuración. Estos scripts se ejecutarán cada
-vez que se ejecuten los comandos #{lb config}# o #{lb clean}# de manera
-automática. Esto asegurará que la configuración se mantendrá consistente
-desde una versión a otra y desde una versión de las herramientas live-build
-a otra. (Aunque esto no elimina la necesidad de leer la documentación cuando
-se instale una nueva version de las herramientas live-build y quizás
-realizar algún ajuste manual en los ficheros de configuración).
-
-2~ Un ejemplo de scripts auto.
-
-Se debe utilizar scripts auto similares a los ejemplos que se muestran a
-continuación como punto de partida para nueva configuración de las
-herramientas live-build. Hay que hacer notar que, cuando se ejecuta el
-comando #{lb}# dentro del script auto, se debe especificar la opción
-#{noauto}# para asegurar que el script auto no es vuelto a ejecutar
-repetitivamente. Tampoco se debe olvidar el asegurar que los scripts auto
-deben ser ejecutables (por ejemplo #{chmod 755 auto/*}#).
-
-#{auto/config}#
-
-code{
-
-#!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-Estos scripts auto vienen de serie con las herramientas live-build. Bastaría
-con copiar estos scripts como punto de partida.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Se puede editar el script #{auto/config}#, modificándolo o añadiendo
-cualquier opción que se acomode a las necesidades requeridas. En el ejemplo
-anterior, se asignará la opción #{--packages-lists standard}# como si fuese
-asignada por defecto. Se puede cambiar este valor a uno adecuado o
-simplemente eliminarlo si no es necesario añadiendo cualquier otra opción
-que se adecue a las necesidades requeridas por la imagen a crear, en líneas
-como las siguientes.
diff --git a/manual/es/user_overview.ssi b/manual/es/user_overview.ssi
deleted file mode 100644
index 869ef06..0000000
--- a/manual/es/user_overview.ssi
+++ /dev/null
@@ -1,168 +0,0 @@
-:B~ Descripción general de las herramientas
-
-1~overview-of-tools Descripción general de las herramientas
-
-Este capítulo contiene una descripción general de las tres herramientas
-principales utilizadas en la creación de sistemas Debian Live: live-build,
-live-boot y live-config.
-
-2~live-build live-build
-
-live-build es una colección de scripts para generar los sistemas Debian
-Live. A estos scripts también se les conoce como «comandos».
-
-La idea detrás de live-build es ser un marco (framework) que utiliza un
-directorio de configuración para automatizar completamente y personalizar
-todos los aspectos de la creación de una imagen de un sistema en vivo.
-
-Muchos conceptos son similares a las del paquete de herramientas de Debian
-debhelper escrito por Joey Hess:
-
-_* Los scripts tienen una ubicación central para la configuración de su
-funcionamiento. En debhelper, éste es el subdirectorio #{debian/}# de un
-árbol de paquetes. Por ejemplo, dh_install buscará, entre otros, un fichero
-llamado #{debian/install}# para determinar qué ficheros deben existir en un
-paquete binario en particular. De la misma manera, live-build almacena toda
-su configuración bajo un subdirectorio #{config/}#.
-
-_* Los scripts son independientes - es decir, siempre es seguro ejecutar
-cada comando.
-
-A diferencia de debhelper, live-build contiene una herramienta para crear un
-directorio de configuración en esqueleto, #{lb config}#. Ésto podría ser
-considerado como similar a herramientas tales como #{dh-make}#. Para obtener
-más información sobre #{lb config}#, consultar {El comando lb config
-}#lb-config
-
-El resto de esta sección describe los tres comandos más importantes:
-
-_* *{lb config}*: Responsable de la creación de un directorio de
-configuración del sistema en vivo. Ver {El comando lb config}#lb-config para
-más información.
-
-_* *{lb build}*: Responsable de iniciar la creación de un sistema en
-vivo. Ver {El comando lb build}#lb-build para más información.
-
-_* *{lb clean}*: Responsable de la eliminación de partes de la creación de
-un sistema en vivo. Ver {El comando lb clean}#lb-clean para más
-información.
-
-3~lb-config El comando #{lb config}#
-
-Como se comentó en {live-build}#live-build, los scripts que componen
-live-build obtienen su configuración desde un único directorio llamado
-#{config/}#. Como la creación de este directorio a mano sería largo y
-propenso a errores, se puede utilizar el comando #{lb config}# para crear el
-esqueleto de directorios de configuración.
-
-Ejecutar #{lb config}# sin argumentos crea un subdirectorio #{config/}# que
-se completa con algunas opciones por defecto:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-Usar #{lb config}# sin ningún argumento sería conveniente para los usuarios
-que necesitan una imagen muy básica, o que tienen intención de proporcionar
-más tarde una configuración más completa a través de auto/config (ver
-{Gestionar una configuración}#managing-a-configuration para más detalles).
-
-Normalmente, se tendrá que especificar algunas opciones. Por ejemplo, para
-incluir la lista del paquete 'gnome' en la configuración:
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-Es posible especificar muchas opciones, tales como:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-Una lista completa de opciones está disponible en la página del manual
-#{lb_config}#.
-
-3~lb-build El comando #{lb build}#
-
-El comando #{lb build}# lee la configuración del directorio config/ A
-continuación, ejecuta los comandos del nivel inferior más bajo necesarios
-para crear el sistema en vivo.
-
-3~lb-clean El comando #{lb clean}#
-
-El comando #{lb clean}# es el encargado de eliminar varias partes de una
-creación de forma que las creaciones posteriores puedan comenzar de forma
-limpia. Por defecto se eliminan las etapas #{chroot}#, #{binary}# y
-#{source}# pero se deja el caché intacto. Además, se pueden limpiar etapas
-de forma individual. Por ejemplo, si se han realizado cambios que sólo
-afectan a la etapa binary, se debe usar #{lb clean --binary}# antes de crear
-una nueva binary. Ver el manual de #{lb_clean}# para una lista detallada de
-todas sus opciones
-
-2~live-boot El paquete live-boot
-
-live-boot es una colección de scripts que proporcionan scripts gancho
-(hooks) para initramfs-tools, que sirve para generar un initramfs capaz de
-arrancar los sistemas en vivo, tales como los creados por live-build. Ésto
-incluye las ISOs de Debian Live, archivos comprimidos en tar de netboot, e
-imágenes para llaves USB.
-
-En el momento del arranque, buscará en los medios de almacenamiento de sólo
-lectura un directorio "/ live" donde se encuentra un sistema de ficheros
-raíz (a menudo una imagen del sistema de ficheros comprimidos como
-squashfs). Si lo encuentra, creará un entorno de escritura, utilizando aufs,
-para que arranquen los sistemas tipo Debian.
-
-Se puede encontrar más información sobre ramfs inicial en Debian en el
-Manual del kernel Debian Linux en http://kernel-handbook.alioth.debian.org/
-concretamente en el capítulo sobre initramfs.
-
-2~live-config El paquete live-config
-
-live-config consiste en una serie de scripts que se ejecutan en el arranque
-después de live-boot para configurar el sistema en vivo de forma
-automática. Se ocupa de tareas como la creación del nombre del equipo
-(hostname), las variantes locales y la zona horaria, crear el usuario en
-vivo, la inhibición de trabajos de cron y el inicio de sesión automático del
-usuario en vivo.
diff --git a/manual/fr/_sisu/.empty b/manual/fr/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/fr/_sisu/image/.empty b/manual/fr/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/fr/_sisu/sisurc.yml b/manual/fr/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/fr/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/fr/_sisu/skin/doc/skin_debian-live.rb b/manual/fr/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/fr/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/fr/about_manual.ssi b/manual/fr/about_manual.ssi
deleted file mode 100644
index aaebc88..0000000
--- a/manual/fr/about_manual.ssi
+++ /dev/null
@@ -1,280 +0,0 @@
-:B~ À propos de ce manuel
-
-1~about-manual À propos de ce manuel
-
-L'objectif principal de ce manuel est servir de point d'accès unique à tous
-les documents liés au projet Debian Live. Tandis qu'il est principalement
-sur vous aider à construire un système Live et non pas sur des sujets de
-l'utilisateur final, un utilisateur final peut trouver des informations
-utiles dans ces sections: {Les Bases}#the-basics couvrent la préparation des
-images pour être démarrées à partir des médias ou depuis le réseau, et
-{Personnalisation des comportements au moment de
-l'exécution}#customizing-run-time-behaviours décrit certaines options qui
-peuvent être spécifiées à l'invite de démarrage, tels que la sélection d'un
-clavier, des paramètres régionaux, et la utilisation de la persistance.
-
-Certaines commandes mentionnées dans le texte doivent être exécutées avec
-les privilèges super-utilisateur, qui peuvent être obtenu en devenant root à
-l'aide de #{su}# ou en utilisant #{sudo}#. Afin de distinguer les commandes
-qui peuvent être exécutées par un utilisateur sans privilèges de celles
-nécessitant les privilèges super-utilisateur, les commandes sont précédées
-respectivement par #{$}# ou #{#}#. Ce symbole ne fait pas partie de la
-commande.
-
-2~ Pour les impatients
-
-Même si nous croyons que tout dans ce manuel est important pour au moins
-certains de nos utilisateurs, nous nous rendons compte qu'il y a beaucoup de
-matière à couvrir et que vous pouvez expérimenter avant d'entrer dans les
-détails. Par conséquent, nous avons fourni trois tutoriels dans la section
-{Exemples}#examples destinée à vous apprendre la construction de l'image et
-les bases de la personnalisation. Lire en premier {En utilisant les
-exemples}#using-the-examples, suivie par {Tutoriel 1: Une image
-standard}#tutorial-1, {Tutoriel 2: Un logiciel de navigateur Web}#tutorial-2
-et finalement {Tutoriel 3: Une image personnalisée}#tutorial-3. À la fin de
-ces tutoriels, vous aurez un avant-goût de ce qui peut être fait avec Debian
-Live. Nous vous encourageons à revenir à l'étude plus approfondie du manuel,
-la prochaine lecture peut-être {Les bases}#the-basics, passer pour
-{Construire une image netboot}#building-netboot-image, et finissant par la
-lecture de la{Vue d'ensemble de la personnalisation}#customization-overview
-et les autres sections suivantes. En ce point, nous espérons que vous êtes
-complètement excités par ce que on peut faire avec Debian Live et motivés
-pour lire le reste du manuel, du début à la fin
-
-2~terms Terminologie
-
-_* *{Système Live}*: Un système d'exploitation pouvant être démarré sans
-installation préalable sur disque dur. Les Systèmes Live ne modifient pas le
-système d'exploitation local ou les fichiers installés sur le disque dur
-sans qu'on leur en donne explicitement l'instruction. D'habitude, les
-systèmes Live sont démarrés à partir de media tels que des CD, DVD, ou des
-clés USB. Certains peuvent également être démarrés depuis le réseau.
-
-_* *{Debian Live}*: Le sous-projet Debian qui maintient les paquets
-live-boot, live-build, live-config, et live-manual.
-
-_* *{Système Debian Live}*: Un système live qui utilise les logiciels du
-système d'exploitation Debian et qui peut être lancé depuis CD, DVD, clé
-USB, en réseau (à l'aide des images netboot), et à partir d'Internet (à
-l'aide du paramètre de démarrage #{fetch=URL}#).
-
-_* *{Système hôte}*: L'environnement utilisé pour créer le système live.
-
-_* *{Système de destination}*: L'environnement utilisé pour faire tourner le
-système live.
-
-_* *{live-boot}*: Une collection de scripts utilisés pour lancer des
-systèmes live. live-boot faisait initialement partie de live-initramfs.
-
-_* *{live-build}*: Une collection de scripts utilisés pour personnaliser les
-systèmes Debian Live. live-build était initialement nommé live-package, puis
-live-helper.
-
-_* *{live-config}*: Une collection de scripts utilisés pour configurer un
-système live durant le processus de démarrage. live-config faisait
-initialement partie de live-initramfs.
-
-_* *{live-manual}*: Ce document est maintenu dans un paquet nommé
-live-manual.
-
-_* *{Debian Installer (d-i)}*: Le système d'installation officiel pour la
-distribution Debian.
-
-_* *{Paramètres de démarrage}*: Les paramètres pouvant être entrés à
-l'invite de démarrage afin de modifier le kernel ou live-config.
-
-_* *{chroot}*: Le programme chroot, #{chroot(8)}#, nous permet de faire
-tourner plusieurs instances concurrentes de l'environnement GNU/Linux sur un
-système sans redémarrage.
-
-_* *{Image binaire}*: Un fichier contenant le système live, tel que
-binary.iso ou binary.img.
-
-_* *{Distribution de destination}*: La distribution sur laquelle votre
-système live sera basée. Ceci peut varier en fonction de la distribution de
-votre système hôte.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Debian noms de code
-pour les versions. Au moment de la rédaction, Squeeze est le courant version
-*{stable}* et Wheezy est la version actuelle *{testing}*. Sid sera toujours
-synonyme de la version *{unstable}*. Tout au long du manuel, nous avons
-tendance à utiliser des noms de code pour les versions, car c'est ce qui est
-supporté par les outils eux-mêmes.
-
-La distribution *{stable}* contient la dernière version officielle de
-Debian. La distribution *{testing}* est la future version stable où seuls
-les paquets suffisamment matures peuvent entrer. Un avantage de cette
-distribution est qu'elle contient des logiciels de versions plus récentes
-que la version *{stable}*. La distribution *{unstable}* est en constante
-évolution. En général cette distribution est utilisée par les développeurs
-et ceux qui aiment le risque.
-
-2~ Auteurs
-
-La liste des auteurs (dans l'ordre alphabétique):
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Contribuer à ce document
-
-Ce manuel est conçu comme un projet communautaire et toutes les propositions
-d'améliorations et de contributions sont bienvenues. La meilleure façon de
-soumettre une contribution est de l'envoyer à la liste de diffusion. S'il
-vous plaît voir {Contact}#contact pour plus d'informations.
-
-Lorsque vous soumettez une contribution, veuillez indiquer clairement le
-copyright et inclure la mention légale relative à la licence. Notez que pour
-être acceptée, la contribution doit être déposée sous la même licence que le
-reste du document, c'est-à-dire la GPL version 3 ou ultérieure.
-
-Les sources de ce manuel sont maintenues à l'aide du logiciel de gestion de
-versions Git. Vous pouvez obtenir la dernière copie en exécutant:
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Avant de soumettre votre contribution, veuillez prévisualiser votre
-travail. Afin de prévisualiser live-manual, assurez-vous que les paquets
-nécessaires sont installés en exécutant:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-Vous pouvez compiler live-manual depuis le répertoire racine de votre
-checkout git en exécutant:
-
-code{
-
- $ make build
-
-}code
-
-Comme il faut un certain temps pour construire le manuel dans toutes les
-langues disponibles, il peut être pratique construire pour une seule langue,
-par exemple en exécutant:
-
-code{
-
- $ make build LANGUAGES=en
-
-}code
-
-3~ Appliquer des patches
-
-Les contributions directes au référentiel sont possibles pour tout le
-monde. Cependant, nous vous demandons d'envoyer les changements conséquents
-sur la liste de diffusion au préalable. Afin de faire un push sur le
-référentiel, les étapes suivantes sont nécessaires.
-
-_* Téléchargez la clé publique:
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Ajoutez la section suivante à votre configuration openssh-client:
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Clonez le manuel via ssh:
-
-code{
-
- $ git clone git at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Notez que vous devez livrer des changements sur la branche debian-next,
-pas sur la branche debian.
-
-_* Après édition des fichiers dans #{manual/en/}#, veuillez appeler 'commit'
-dans le dossier racine du répertoire afin de nettoyer les fichier et de
-mettre à jour les fichiers de traduction:
-
-code{
-
- $ make commit
-
-}code
-
-_* Après nettoyage, soumettre les modifications. Veuillez écrire les
-commentaires de commit à l'aide de phrases complètes, en commençant par une
-majuscule et en terminant par un point, et en commençant par
-'Fixing/Adding/Removing/Correcting/Translating', par exemple
-
-code{
-
- $ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Envoyez votre commit au serveur:
-
-code{
-
- $ git push
-
-}code
-
-3~ Traduction
-
-Pour soumettre une traduction pour une nouvelle langue, suivez ces trois
-étapes:
-
-_* Traduire les fichiers about_manual.ssi.pot, about_project.ssi.pot et
-index.html.in.pot à votre langue avec votre éditeur préféré (comme
-poedit). Envoyer les fichiers traduits à la liste de diffusion. Une fois que
-nous avons examiné votre livraison, nous allons ajouter une nouvelle langue
-au manuel (avec les fichiers po) et l'activer dans l'autobuild.
-
-_* Une fois la nouvelle langue est ajoutée, vous pouvez commencer à traduire
-de façon aléatoire tous les fichiers po dans #{manual/po/}#.
-
-_* N'oubliez pas que vous devez #{make commit}# pour assurer la traduction
-des manuels sont mis à jour à partir des fichiers po, avant #{git commit
--a}# et #{git push}#.
diff --git a/manual/fr/about_project.ssi b/manual/fr/about_project.ssi
deleted file mode 100644
index 24a566e..0000000
--- a/manual/fr/about_project.ssi
+++ /dev/null
@@ -1,117 +0,0 @@
-:B~ À propos du projet Debian Live
-
-1~about-project À propos du projet Debian Live
-
-2~ Motivation
-
-3~ Quel est le problème avec les systèmes live actuels
-
-Lorsque Debian Live a été lancé, il y avait déjà plusieurs systèmes live
-basés sur debian et ils faisaient un excellent travail. Du point de vue de
-Debian la plupart d'entre eux ont un ou plusieurs des inconvénients
-suivants:
-
-_* Ils ne sont pas des projets de Debian, et donc ils manquent de soutien au
-sein de Debian.
-
-_* Ils mélangent les différentes distributions p. ex *{testing}* et
-*{unstable}*.
-
-_* Ils supportent seulement i386.
-
-_* Ils modifient le comportement et/ou l'apparence des paquets en les
-dépouillant pour économiser l'espace.
-
-_* Ils comprennent des paquets provenant en dehors de l'archive Debian.
-
-_* Ils offrent kernels personnalisés avec des patches supplémentaires qui ne
-font pas partie de Debian.
-
-_* Ils sont grands et lents en raison de leur dimension et donc pas
-recommandés comme systémes de sauvetage.
-
-_* Ils ne sont pas disponibles en différents formats, p. ex. CDs, DVDs, clés
-USB et images netboot.
-
-3~ Pourquoi créer notre propre système live?
-
-Debian est le système d'exploitation universel: Debian a un système live
-pour montrer autour et pour représenter le vrai, seul et unique système
-Debian avec les principaux avantages suivants:
-
-_* Ce serait un sous-projet de Debian.
-
-_* Il reflète l'état (actuel) d'une distribution.
-
-_* Il fonctionne sur le plus grand nombre d'architectures possible.
-
-_* Il seulement se compose de paquets Debian inchangés.
-
-_* Il ne contient pas de paquets qui ne sont pas dans l'archive Debian.
-
-_* Il utilise un kernel Debian inchangé sans patches supplémentaires.
-
-2~ Philosophie
-
-3~ Seulement des paquets inchangés de Debian «main»
-
-Nous seulement utiliserons les paquets du référentiel de Debian dans la
-section «main ». La section non-free ne fait pas partie de Debian et ne peut
-donc pas être utilisée pour les images officiels du système live.
-
-Nous ne changerons pas les paquets. Chaque fois que nous avons besoin de
-changer quelque chose, nous le ferons en coordination avec le responsable du
-paquet dans Debian.
-
-À titre d'exception, nos propres paquets tels que live-boot, live-build ou
-live-config peuvent être utilisés temporairement à partir de notre propre
-référentiel pour raisons de développement (par exemple pour créer des
-instantanés de développement). Ils seront téléchargés sur Debian
-régulièrement.
-
-3~ Pas de configuration des paquets du système live
-
-Dans cette phase, nous n'offerons configurations alternatives. Tous les
-paquets sont utilisés dans leur configuration par défaut comme ils sont
-après une installation standard de Debian.
-
-Chaque fois que nous avons besoin d'une configuration par défaut différent,
-nous le ferons en coordination avec le responsable du paquet dans Debian.
-
-Un système de configuration des paquets est fourni avec debconf dans #{lb
-config}# (utiliser --preseed FICHIER) permettant la personnalisation des
-paquets installés sur votre image Debian Live, mais pour les images
-officielles seulement sera utilisé une configuration par défaut. Pour plus
-d'informations, s'il vous plaît voir {Vue d'ensemble de la
-personnalisation}#customization-overview.
-
-Exception: Il y a quelques changements essentiels nécessaires pour mettre un
-système live en marche (par exemple la configuration de pam pour permettre
-des mots de passe vide). Ces changements essentiels doivent être maintenus
-aussi minimes que possible et devraient être fusionnées au sein du
-référentiel Debian s'il est possible.
-
-2~contact Contact
-
-_* *{Liste de diffusion}*: Le contact principal du projet est la liste de
-diffusion http://lists.debian.org/debian-live/. Vous pouvez envoyer un
-courriel à la liste directement en adressant votre courrier à
-debian-live at lists.debian.org. Les archives de la liste sont disponibles à
-http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: Un certain nombre d'utilisateurs et les développeurs sont
-présents dans le canal #debian-live sur irc.debian.org (OFTC). Quand vous
-posez une question sur IRC, s'il vous plaît soyez patient en attendant une
-réponse. Si aucune réponse n'est donnée, s'il vous plaît envoyez un courriel
-à la liste de diffusion.
-
-_* *{BTS}*: Le Debian Bug Tracking System (BTS) contient les détails des
-bugs rapportés par les utilisateurs et les développeurs. Chaque bug reçoit
-un numéro, et il est conservé jusqu'à ce qu'il soit marqué comme
-traité. Pour plus d'informations, s'il vous plaît voir {Rapporter des
-bugs}#bugs.
-
-_* *{Wiki}*: Le wiki Debian Live à http://wiki.debian.org/DebianLive est un
-lieu pour recueillir des informations, discuter des technologies appliquées,
-et structures des systèmes Debian Live qui vont au-delà de la portée de ce
-document.
diff --git a/manual/fr/index.html.in b/manual/fr/index.html.in
deleted file mode 100644
index 268e942..0000000
--- a/manual/fr/index.html.in
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-
-<head>
- <title>Projet Debian Live</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Manuel Debian Live</h2>
-
- <p>
- Veuillez transmettre les erreurs, omissions, patches et suggestions sur
-notre liste de discussion <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>
-et lire <a href="html/about-manual.html#how-to-contribute">comment
-contribuer</a> au manuel.
- </p>
-
- <h3>Formats disponibles</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">multi pages</a>, <a
-href="html/live-manual.html">page unique</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 portrait</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 paysage</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">US portrait</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">US paysage</a></li>
- <li><a href="txt/live-manual.txt">Texte brut</a></li>
- </ul>
-
- <p>
- Dernière modification: @DATE_CHANGE@<br />
- Dernière compilation: @DATE_BUILD@
- </p>
-
- <h3>Source</h3>
-
- <p>
- Les sources de ce manuel sont disponibles dans un répertoire <a
-href="http://git.or.cz/">Git</a> sur live.debian.net.
- </p>
-
- <ul>
- <li>Parcourir: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Note légale</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/fr/live-manual.ssm b/manual/fr/live-manual.ssm
deleted file mode 100644
index e651ed9..0000000
--- a/manual/fr/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Manuel Debian Live
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: Ce programme est un logiciel libre; vous pouvez le redistribuer ou le modifier suivant les termes de la Licence Générale Publique GNU telle que publiée par la Free Software Foundation: soit la version 3 de cette licence, soit (à votre gré) toute version ultérieure.<br><br>Ce programme est distribué dans l’espoir qu’il vous sera utile, mais SANS AUCUNE GARANTIE: sans même la garantie implicite de COMMERCIALISABILITÉ ni d’ADÉQUATION À UN OBJECTIF PARTICULIER. Consultez la Licence Générale Publique GNU pour plus de détails.<br><br>Vous devriez avoir reçu une copie de la Licence Générale Publique GNU avec ce programme ; si ce n’est pas le cas, consultez http://www.gnu.org/licenses/. <br><br>Le texte complet de la Licence Générale Publique GNU peut être trouvé dans le fichier / usr/share/common-licenses/GPL-3
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ À propos
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ Utilisateur
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Projet
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Exemples
-
-<< user_examples.ssi
diff --git a/manual/fr/project_bugs.ssi b/manual/fr/project_bugs.ssi
deleted file mode 100644
index dd25ee5..0000000
--- a/manual/fr/project_bugs.ssi
+++ /dev/null
@@ -1,213 +0,0 @@
-B~ Rapporter des bogues
-
-1~bugs Rapporter des bogues
-
-Debian Live est loin d'être parfait, mais nous voulons le rendre aussi
-proche que possible de parfait - avec votre aide. N'hésitez pas à signaler
-un bogue: il est préférable de remplir un rapport deux fois plus que
-jamais. Toutefois, ce chapitre contient des recommandations pour déposer les
-rapports de bogues.
-
-Pour les impatients:
-
-_* Commencez toujours par vérifier les mises à jour de la situation de
-l'image sur notre page d'accueil http://live.debian.net/ pour voir les
-problèmes connus.
-
-_* Toujours essayer de reproduire le bogue avec *{les versions les plus
-récents}* de live-build, live-boot, et live-config avant de présenter un
-rapport de bogue.
-
-_* Essayez de donner des informations aussi précises que possible sur le
-bogue. Cela comprend (au moins) la version de live-build, live-boot et
-live-config, de la distribution utilisée et du système live que vous
-construisez.
-
-2~ Problèmes connus
-
-Parce que les distributions Debian *{testing}* et Debian *{unstable}* sont
-une cible mouvante, quand vous les spécifiez comme la distribution du
-système cible, une construction avec succès n'est pas toujours possible.
-
-% FIXME:
-
-Si cela provoque trop de difficulté pour vous, ne pas construire un système
-basé sur *{testing}* or *{unstable}*, mais plutôt utiliser
-*{stable}*. live-build fait toujours défaut à la version *{stable}*.
-
-Les problèmes connus sont énumérés sous la section "status" sur notre page à
-http://live.debian.net/.
-
-Il est hors cadre de ce manuel vous former correctement à identifier et
-corriger les problèmes dans les paquets des distributions de développement,
-cependant, il y a deux choses que vous pouvez toujours essayer: Si une
-construction échoue lorsque la distribution cible est *{testing}*, essayez
-*{unstable}*. Si *{unstable}* ne fonctionne pas non plus, revenir à
-*{testing}* et fixer la nouvelle version du paquet qui échoue à partir de
-*{unstable}* (voir {APT pinning}#apt-pinning pour plus de détails).
-
-2~ Reconstruire à partir de zéro
-
-Afin de s'assurer que un bogue en particulier n'est pas causé par un système
-construit malpropre, s'il vous plaît toujours reconstruire l'ensemble du
-système live à partir de zéro pour voir si le bogue est reproductible.
-
-2~ Utilisez paquets mises à jour
-
-L'utilisation de paquets obsolètes peut causer d'importants problèmes en
-essayant de reproduire (et finalement régler) votre problème. Assurez-vous
-que votre système de construction est mis à jour et tous les paquets inclus
-dans votre image sont mises à jour aussi.
-
-2~collect-information Recueillir l'information
-
-S'il vous plaît fournir assez d'informations à votre rapport. Inclure au
-moins la version exacte de live-build où le bogue est rencontré et les
-mesures pour le reproduire. S'il vous plaît utilisez votre bon sens et
-inclure d'autres renseignements pertinents, si vous pensez que cela pourrait
-aider à résoudre le problème.
-
-Pour tirer le meilleur parti de votre rapport de bogue, nous avons besoin
-d'au moins les informations suivantes:
-
-_* L'architecture du système hôte
-
-_* Version de live-build sur le système hôte
-
-_* Version de live-boot sur le système live
-
-_* Version de live-config sur le système live
-
-_* Version de #{debootstrap}# et/ou #{cdebootstrap}# sur le système hôte
-
-_* L'architecture du système live
-
-_* Répartition du système live
-
-_* Version du noyau sur le système live
-
-Vous pouvez générer un journal du processus de construction en utilisant la
-commande #{tee}#. Nous recommandons de faire cela automatiquement avec un
-script #{auto/build}#; (voir {Gestion d'une
-configuration}#managing-a-configuration pour les détails).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-Au démarrage, live-boot stocke un journal dans #{/var/log/live.log}# (ou
-#{/var/log/live-boot.log}#).
-
-Par ailleurs, pour écarter d'autres erreurs, c'est toujours une bonne idée
-faire un tar de votre répertoire #{config/}# et de le télécharger quelque
-part (*{ne pas}* l'envoyer en pièce jointe à la liste de diffusion), de
-sorte que nous pouvons essayer de reproduire les erreurs que vous
-rencontrez. Si cela est difficile (en raison par exemple de la taille) vous
-pouvez utiliser la sortie de #{lb config --dump}# qui produit un résumé de
-votre arbre de config (c'est-à-dire les listes des fichiers dans les
-sous-répertoires de #{config/}# mais ne les inclut pas).
-
-N'oubliez pas d'envoyer tous les journaux qui ont été produites avec le
-paramètre régionaux anglais, par exemple exécuter vos commandes live-build
-précédées par #{LC_ALL=C}# ou #{LC_ALL=en_US}#.
-
-2~ Isoler le cas qui échoue, si possible
-
-Si possible, isoler le cas qui échoue au plus petit changement possible. Il
-n'est pas toujours facile de faire cela, donc si vous ne pouvez pas le gérer
-pour votre rapport, ne vous inquiétez pas. Toutefois, si vous planifiez
-votre cycle de développement bien, en utilisant petits ensembles de changes
-par itération, vous pourriez être capable d'isoler le problème en
-construisant une configuration simple «base» qui correspond étroitement à la
-configuration réelle avec seulement le changement cassé ajouté. Si il est
-difficile de trier vos modifications que cassent, il est possible que vous y
-compris trop dans chaque ensemble de modifications et devraient se
-développer en petits incréments.
-
-2~ Utilisez le paquet adéquat pour rapporter le bogue
-
-Où est-ce que le bogue apparaît?
-
-3~ Au moment de la construction tandis l'amorçage
-
-live-build amorce (bootstrap) d'abord un système Debian de base avec
-#{debootstrap}# ou #{cdebootstrap}#. Selon l'outil d'amorçage utilisé et de
-la distribution Debian il peut échouer. Si un bogue apparaît ici, vérifiez
-si l'erreur est liée à un paquet Debian spécifique (plus probable), ou si il
-est lié à l'outil d'amorçage lui-même.
-
-Dans les deux cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans
-Debian lui-même que nous ne pouvons résoudre directement. S'il vous plaît
-rapportez un bogue sur l'outil d'amorçage ou du paquet défaillant.
-
-3~ Au moment de la construction tandis l'installation de paquets
-
-live-build installe des paquets supplémentaires de l'archive Debian et en
-fonction de la distribution Debian utilisée et l'état quotidienne de
-l'archive, il peut échouer. Si un bogue apparaît ici, vérifiez si l'erreur
-est également reproductible sur un système normal.
-
-Si c'est le cas, ce n'est pas un bogue dans Debian Live, mais plutôt dans
-Debian - s'il vous plaît faire le rapport sur le paquet
-défaillant. L'exécution de #{debootstrap}# séparément du système de
-construction ou l'exécution de #{lb bootstrap --debug}# vous donnera plus
-d'informations.
-
-Aussi, si vous utilisez un miroir local et/ou un proxy et vous rencontrez un
-problème, s'il vous plaît toujours le reproduire d'abord en amorçant depuis
-un miroir officiel.
-
-3~ Au moment du démarrage
-
-Si votre image ne démarre pas, s'il vous plaît le signaler à la liste de
-diffusion avec les informations demandées dans {Recueillir
-l'information}#collect-information. Ne pas oublier de mentionner,
-comment/quand l'image a échoué, dans Qemu, VirtualBox, VMWare ou matériel
-réel. Si vous utilisez une technologie de virtualisation d'aucune sorte,
-s'il vous plaît toujours tester sur matériel réel avant de rapporter un
-bug. Fournir une copie d'écran de l'échec est également très utile.
-
-3~ Au moment de l'exécution
-
-Si un paquet a été installé avec succès, mais échoue tout en exécutant le
-système Live, c'est probablement un bogue dans Debian Live. Cependant,
-
-2~ Faire les recherches
-
-Avant de présenter le bogue, s'il vous plaît recherchez sur le web pour le
-message d'erreur ou un symptôme particulier que vous obtenez. Comme il est
-hautement improbable que vous êtes la seule personne qui expérience un
-problème particulier, il ya toujours une chance qu'il a été discuté
-ailleurs, et une solution possible, un correctif, ou une solution de
-contournement a été proposé.
-
-Vous devez prêter une attention particulière à la liste de diffusion de
-Debian Live, ainsi que à la page d'accueil, car elles sont susceptibles de
-contenir des informations à jour. Si ces informations existent, toujours
-inclure les références au sein de vos rapport de bogues.
-
-En outre, vous devriez vérifier les listes de bogues en cours de live-build,
-live-boot, et live-config pour voir si quelque chose de semblable n'a été
-déjà signalé.
-
-2~ Où rapporter les bogues
-
-Le projet Debian Live conserve la trace de tous les bogues dans le système
-Debian Bug Tracking System (BTS). Pour plus d'informations sur la façon
-d'utiliser le système, s'il vous plaît voir http://bugs.debian.org/. Vous
-pouvez également soumettre les bogues en utilisant la commande #{reportbug}#
-à partir du paquet du même nom.
-
-En général, vous devez signaler des erreurs de construction contre le paquet
-live-build, des erreurs en temps de démarrage contre live-boot, et erreurs
-d'exécution contre live-config. Si vous n'êtes pas sûr de quel paquet est
-approprié ou avez besoin d'aide avant de soumettre un rapport de bogue, s'il
-vous plaît envoyez un message à la liste de diffusion et nous vous aiderons
-à décider.
-
-S'il vous plaît notez que les bogues trouvés dans les distributions dérivées
-de Debian (comme Ubuntu et autres) *{ne}* doivent *{pas} * être rapportés au
-BTS de Debian, sauf qu'ils peuvent être également reproduits sur un système
-Debian en utilisant les paquets Debian officiels.
diff --git a/manual/fr/project_coding-style.ssi b/manual/fr/project_coding-style.ssi
deleted file mode 100644
index de25f9c..0000000
--- a/manual/fr/project_coding-style.ssi
+++ /dev/null
@@ -1,149 +0,0 @@
-B~ Style du code
-
-1~coding-style Style du code
-
-Ce chapitre documente le style du code utilisé en live-boot et autres.
-
-2~ Compatibilité
-
-_* Ne pas utiliser la syntaxe ou la sémantique qui sont uniques à le shell
-Bash. Par exemple, l'utilisation de structures de tableau.
-
-_* N'utiliser que le sous-ensemble POSIX - par exemple, utiliser $(foo) au
-lieu de `foo`.
-
-_* Vous pouvez vérifier vos scripts avec 'sh -n' et 'checkbashisms'.
-
-2~ Indentation
-
-_* Toujours utiliser des tabulations en lieu des espaces.
-
-2~ Adaptateur
-
-_* Généralement, les lignes sont de 80 caractères au maximum.
-
-_* Utilisez le «style Linux» des sauts de ligne:
-
-Mal:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Bien:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* La même chose vaut pour les fonctions:
-
-Mal:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Bien:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variables
-
-_* Les variables sont toujours en lettres majuscules.
-
-_* Les variables utilisées dans #{lb config}# commencent toujours par le
-préfixe #{LB_}#.
-
-_* Les variables temporaires internes en live-build devraient commencer avec
-le préfixe #{\_LB_}#.
-
-_* Les variables locales commencent avec le préfixe #{\_\_LB_}#.
-
-_* Les variables en relation avec un paramètre de démarrage en live-config
-commencent par #{LIVE_}#.
-
-_* Toutes les autres variables en live-config commencent par le préfixe
-#{_}#.
-
-_* Utilisez des accolades autour des variables; par exemple écrire
-#{${FOO}}# au lieu de #{$FOO}#.
-
-_* Toujours protéger les variables avec guillemets pour respecter les
-espaces potentiels: écrire #{"${FOO}"}# en lieu de #{${FOO}}#.
-
-_* Pour des raisons de cohérence, toujours utiliser les guillemets lors de
-l'attribution des valeurs aux variables:
-
-Mal:
-
-code{
-
- FOO=bar
-
-}code
-
-Bien:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* Si plusieurs variables sont utilisées, utiliser les guillemets pour
-l'expression complète:
-
-Mal:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Bien:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Autres
-
-_* Utilisez "#{|}#" (sans les guillemets autour) comme un séparateur dans
-les appels à sed, par exemple "#{sed -e 's|foo|bar|'}#" (sans" ").
-
-_* Ne pas utiliser la commande #{test}# pour des comparaisons ou des tests,
-utilisez "#{[}#" "#{]}#" (sans ""); par exemple "#{if [ -x /bin/foo ];
-...}#" et non pas "#{if test -x /bin/foo; ...}#".
-
-_* Utiliser #{case}# dans la mesure du possible en lieu de #{test}#, parce
-qu'il est plus facile à lire et plus rapide dans l'exécution.
diff --git a/manual/fr/project_procedures.ssi b/manual/fr/project_procedures.ssi
deleted file mode 100644
index dd926d0..0000000
--- a/manual/fr/project_procedures.ssi
+++ /dev/null
@@ -1,144 +0,0 @@
-B~ Procédures
-
-1~procedures Procédures
-
-Ce chapitre documente les procédures au sein du projet Debian Live pour
-différentes tâches qui ont besoin de la coopération avec d'autres équipes
-dans Debian.
-
-2~ Télécharger Udebs
-
-Avant d'envoyer une version d'un udeb au d-i svn, on doit faire:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Évolutions majeures
-
-La libération d'une nouvelle version stable majeur de Debian inclut beaucoup
-de différentes équipes travaillant ensemble. À un certain point, l'équipe
-Live arrive et construit des images du système live. Les conditions pour ce
-faire sont les suivantes:
-
-_* Un miroir contenant les versions publiées pour les référentiels Debian,
-debian-security et debian-volatile auxquels debian-live buildd peut avoir
-accès.
-
-_* Les noms de l'image doivent être connus (par exemple
-debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* Les listes de paquets doivent être mises à jour.
-
-_* Les données qui proviennent de debian-cd doivent être synchronisées (udeb
-exclude lists).
-
-_* Les includes de debian-cd doivent être synchronisées (README.*, doc/*,
-etc.).
-
-_* Les images sont construites et mises en miroir sur cdimage.debian.org.
-
-2~ Èvolutions mineures
-
-_* Encore une fois, nous avons besoin d'un miroir mise à jour de Debian,
-Debian-security et debian-volatile.
-
-_* Les images sont construites et mises en miroir sur cdimage.debian.org.
-
-_* Envoyer un courrier d'annonce.
-
-3~ Modèle pour l'annonce d'une évolution mineure
-
-Un courrier pour l'annonce d'une évolutioun mineure peut être généré en
-utilisant le modèle ci-dessous et la commande suivante:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-S'il vous plaît vérifiez le courrier avant l'envoi et le passer à d'autres
-pour la relecture.
-
-code{
-
- Debian Live images for Debian GNU/Linux %major% updated
-
- The Debian Live project is pleased to announce the availability of
- updated Live images for its stable distribution Debian GNU/Linux %major%
- (codename "%codename%").
-
- The images are available for download at:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- This update incorporates the changes made in the %minor% point release,
- which adds corrections for security problems to the stable release
- along with a few adjustments for serious problems. A full list of the
- changes may be viewed at:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
- It also includes the following Live-specific changes:
-
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
-
-
- URLs
- ----
-
- Download location of updated images:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Projet Debian Live Homepage:
-
- <http://live.debian.net/>
-
- The current stable distribution:
-
- <http://ftp.debian.org/debian/dists/stable>
-
- stable distribution information (release notes, errata etc.):
-
- <http://www.debian.org/releases/stable/>
-
- Security announcements and information:
-
- <http://www.debian.org/security/>
-
-
- About Debian
- -------------
-
- The Debian Project is an association of Free Software developers who
- volunteer their time and effort in order to produce the completely free
- operating system Debian GNU/Linux.
-
-
- About Debian Live
- -----------------
-
- Debian Live is an official sub-project of Debian which produces Debian
- systems that do not require a classical installer. Images are available
- for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
- filesystem images for booting directly from the internet.
-
-
- Contact Information
- -------------------
-
- For further information, please visit the Debian Live web pages at
- <http://live.debian.net/> or alternatively send mail to
- <debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/fr/user_basics.ssi b/manual/fr/user_basics.ssi
deleted file mode 100644
index d792395..0000000
--- a/manual/fr/user_basics.ssi
+++ /dev/null
@@ -1,561 +0,0 @@
-:B~ Les bases
-
-1~the-basics Les bases
-
-Ce chapitre contient un bref aperçu du procès de construction et des
-instructions pour utiliser les trois types d'images les plus couramment
-utilisées. Le type d'image le plus polyvalent, #{iso-hybrid}#, peut être
-utilisé sur une machine virtuelle, supports optiques ou un périphérique USB
-de stockage portable. Dans certains cas particuliers, tels que l'utilisation
-de la persistance, le type #{usb-hdd}# peut être plus approprié pour les
-périphériques USB. Le chapitre se termine avec des instructions pour la
-construction et l'utilisation d'une image #{net}# , qui est un peu plus
-compliqué en raison de la configuration requise sur le serveur. C'est un
-sujet un peu avancée pour tous ceux qui ne connaissent pas déjà le démarrage
-par le réseau, mais est inclus ici car une fois la configuration est
-terminée, il est un moyen très pratique pour tester et déployer des images
-pour le démarrage sur le réseau local sans le tracas des supports de
-l'image.
-
-Tout au long du chapitre, nous ferons souvent référence à la valeur par
-défaut des noms de fichiers produits par live-build. Si vous téléchargez une
-image précompilée les noms de fichiers peuvent varier.
-
-2~what-is-live Qu'est-ce qu'un système live?
-
-Un système live signifie généralement un système d'exploitation démarré sur
-un ordinateur à partir d'un support amovible, tel qu'un CD-ROM ou une clé
-USB, ou d'un réseau prêt à l'emploi sans aucune installation sur le disque
-habituel(s), avec auto-configuration fait lors de l'exécution (voir
-{Termes}#terms).
-
-Avec Debian Live, c'est un système Debian GNU/Linux, construit pour une des
-architectures supportées (actuellement amd64, i386, PowerPC et SPARC). Il
-est fait à partir des éléments suivants:
-
-_* *{Linux kernel image}*, d'habitude appelé #{vmlinuz*}#
-
-_* *{Initial RAM disk image (initrd)}*: Un disque virtuel RAM configuré pour
-le démarrage de Linux, contenant possiblement des modules nécessaires pour
-monter l'image du système et certains scripts pour le faire.
-
-_* *{System image}*: L'image du système de fichiers du système
-d'exploitation. Habituellement, un système de fichiers SquashFS comprimé est
-utilisé pour réduire au minimum la taille de l'image Debian Live. Notez
-qu'il est en lecture seulement. Ainsi, lors du démarrage du système Debian
-Live nous allons utiliser un disque RAM et un mécanisme "union" pour
-permettre l'écriture de fichiers dans le système en marche. Cependant,
-toutes les modifications seront perdues lors de l'arrêt à moins que l'option
-persistance est utilisée (voir {Persistance}#persistence).
-
-_* *{Bootloader}*: Un petit morceau de code conçu pour démarrer à partir du
-support choisi, il peut présenter un menu rapide ou permettre la sélection
-des options/configuration. Il charge le kernel Linux et son initrd pour
-fonctionner avec un système de fichiers associé. Différentes solutions
-peuvent être utilisées, selon le support de destination et le format du
-système de fichiers contenant les composants mentionnés précédemment:
-isolinux pour démarrer à partir d'un CD ou DVD au format ISO9660, syslinux
-pour démarrer le disque dur ou clé USB à partir d'une partition VFAT,
-extlinux pour ext2/3/4 et partitions btrfs, pxelinux pour netboot PXE, GRUB
-pour ext2/3/4 partitions, etc.
-
-Vous pouvez utiliser live-build pour construire l'image du système à partir
-de vos spécifications, configurer un kernel Linux, son initrd, et un
-chargeur de démarrage pour les exécuter, tout dans un format en fonction du
-support (image ISO9660, disque image, etc.)
-
-2~building-iso-hybrid Premières étapes: la construction d'une image ISO
-hybride
-
-Quel que soit le type d'image, vous devrez effectuer les mêmes étapes de
-base pour créer une image chaque fois. Comme premier exemple, exécuter la
-séquence suivante de commandes live-build pour créer une image ISO hybride
-de base contenant tout le système Debian standard sans X.org. Elle est
-appropriée pour être gravée sur CD ou DVD, et également peut être copiée sur
-une clé USB.
-
-Tout d'abord, exécutez la commande #{lb config}#. Cela va créer une
-hiérarchie "config /" dans le répertoire courant pour l'utilisation par
-d'autres commandes:
-
-code{
-
- $ lb config
-
-}code
-
-Aucun paramètre n'est passé à #{lb config}#, donc défauts seront utilisés
-pour l'ensemble de ses diverses options. Voir {La commande lb
-config}#lb-config pour plus de détails.
-
-Maintenant que la hiérarchie "config /" existe, créez l'image avec la
-commande #{lb build}# :
-
-code{
-
- # lb build
-
-}code
-
-Ce processus peut prendre un certain temps, en fonction de la vitesse de
-votre connexion réseau. Quand il est complet, il devrait y avoir un fichier
-image #{binary-hybrid.iso}# prêt à l'emploi, dans le répertoire courant.
-
-2~using-iso-hybrid Utilisation d'une image ISO hybride live
-
-Après la construction ou le téléchargement d'une image ISO hybride, qui peut
-être obtenue à http://www.debian.org/CD/live/, l'étape suivante est
-d'habitude préparer votre support pour le démarrage, soit sur CD-R(W) ou DVD
--R(W) des supports optiques ou une clé USB.
-
-3~burning-iso-image Graver une image ISO sur un support physique
-
-Graver une image ISO est facile. Il suffit d'installer wodim et l'utiliser à
-partir de la ligne de commande pour graver l'image. Par exemple:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copie d'un image ISO hybride sur une clé USB
-
-Les images ISO préparées avec la commande #{isohybrid}# comme les images
-#{iso-hybrid}# produites par défaut, peuvent être simplement copiées sur une
-clé USB avec #{dd}# ou un programme équivalent. Brancher une clé USB avec
-une capacité suffisamment grande pour votre fichier image et déterminez quel
-dispositif il est, que nous appellons ci-dessous #{${USBSTICK}}#. C'est le
-fichier de périphérique de votre clé, tel que #{/dev/sdb}#, pas une
-partition, tel que #{/dev/sdb1}#! Vous pouvez trouver le nom du périphérique
-en regardant dans la sortie de #{dmesg}# après avoir branché le dispositif,
-ou mieux encore, #{ls -l /dev/disk/by-id}#.
-
-Une fois que vous êtes sûr d'avoir le nom correct de l'appareil, utilisez la
-commande #{dd}# pour copier l'image sur le clé. *{Ceci écrasera tout fichier
-déjà existant sur votre clé!}*
-
-code{
-
- $ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Démarrer le support live
-
-La première fois que vous démarrez votre support live, qu'il s'agisse de CD,
-DVD, clé USB, ou le démarrage PXE, une certaine configuration dans le BIOS
-de votre ordinateur peut être d'abord nécessaire. Depuis les BIOS varient
-grandement en fonctionnalités et raccourcis clavier, on ne peut pas pénétrer
-dans le sujet en profondeur ici. Certains BIOS fournissent une clé pour
-ouvrir un menu d'amorçage au démarrage, qui est le moyen le plus facile si
-elle est disponible sur votre système. Sinon, vous avez besoin d'entrer dans
-le menu de configuration du BIOS et modifier l'ordre de démarrage pour
-placer le dispositif de démarrage pour le système live devant votre
-périphérique de démarrage normal.
-
-Une fois que vous avez démarré le support, vous êtes présenté avec un menu
-de démarrage. Si vous appuyez simplement sur enter ici, le système va
-démarrer en utilisant l'entrée par défaut, #{Live}# Pour plus d'informations
-sur les options de démarrage, consultez l'entrée «Help» dans le menu et
-aussi les pages de manuel de #{live-boot}# et #{live-config}# dans le
-système live.
-
-En supposant que vous avez sélectionné #{Live}# et démarré une image de
-bureau live par défaut, après les messages de démarrage défilent, vous
-devriez être automatiquement connecté au compte #{user}# et voir un bureau,
-prêt à l'emploi. Si vous avez démarré une image de la console uniquement,
-tels que saveurs #{standard}# ou #{sauvetage}# des images prédéfinies, vous
-devriez être automatiquement connecté à la console pour le compte #{user}#
-et voir une invite du shell, prêt à l'emploi.
-
-2~using-virtual-machine Utiliser une machine virtuelle pour les tests
-
-Il peut être un gain de temps important pour le développement des images
-live les faire fonctionner dans une machine virtuelle (VM). Ce n'est pas
-sans ses avertissements:
-
-_* L'exécution d'une VM demande assez de RAM pour l'OS client et l'hôte et
-un CPU avec support matériel pour la virtualisation est recommandée.
-
-_* Il ya quelques limitations inhérentes à l'exécution sur une VM, par
-exemple performance de vidéo médiocre, ou choix limité de matériel émulé.
-
-_* Lors du développement d'un matériel spécifique, il n'existe aucun
-substitut pour l'exécution que le matériel lui-même.
-
-_* Parfois il ya des bogues que deviennent visibles uniquement pendant
-l'exécution dans une VM. En cas de doute, testez votre image directement sur
-le matériel.
-
-À condition que vous pouvez travailler avec ces obstacles, examinez les
-logiciels VM disponibles et choisissez celui qui convient à vos besoins.
-
-3~testing-iso-with-qemu Test d'une image ISO avec QEMU
-
-La VM la plus polyvalente de Debian est QEMU. Si votre processeur possède un
-support matériel pour la virtualisation, vouz pouvez utiliser le paquet
-#{qemu-kvm}#; La description du paquet #{qemu-kvm}# énumère brièvement les
-exigences.
-
-Tout d'abord, installez #{qemu-kvm}# si votre processeur le supporte. Sinon,
-installez #{qemu}#, dans ce cas, le nom du programme est #{qemu}# au lieu de
-#{kvm}# dans les exemples suivants. Le paquet #{qemu-utils}# est également
-valuable pour créer des images disque virtuels avec #{qemu-img}#.
-
-code{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Démarrer une image ISO est simple:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-Voir les pages de manuel pour plus de détails.
-
-3~testing-iso-with-virtualbox Test d'une image ISO avec virtualbox-ose
-
-Afin de tester l'ISO avec #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Créer une nouvelle machine virtuelle, modifiez les paramètres de stockage
-pour utiliser #{binary-hybrid.iso}# comme le périphérique CD/DVD et démarrer
-la machine.
-
-Remarque: Pour les systèmes live contenant X.org que vous voulez essayer
-avec #{virtualbox-ose}#, vous pouvez inclure le paquet des pilotes
-VirtualBox X.org, #{virtualbox-ose-guest-x11}#, dans votre configuration de
-live-build. Sinon, la résolution est limitée à 800x600.
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Construction d'une image USB/HDD
-
-La construction d'une image USB/HDD est similaire à une ISO hybride à tous
-les égards, sauf que vous spécifiez #{-b usb-hdd}# et le nom du fichier
-résultant est #{binary.img}# qui ne peut être brûlé sur des supports
-optiques. Il convient pour le démarrage à partir de clés USB, disques durs
-USB, et divers autres dispositifs de stockage portables. Normalement, une
-image ISO hybride peut être utilisé à cette fin au lieu, mais si vous avez
-un BIOS qui ne gère pas correctement des images hybrides, ou si vous voulez
-utiliser l'espace disponible sur le support à certaines fins, tel que la
-persistance d'une partition, vous devez utiliser une image USB/HDD.
-
-Remarque: si vous avez créé une image ISO hybride avec l'exemple précédent,
-vous devrez nettoyer votre répertoire de travail avec la commande #{lb
-clean}# (voir {La commande lb clean}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Exécutez la commande #{lb config}# comme avant, sauf que cette fois en
-spécifiant le type d'image USB/HDD:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Maintenant construire l'image avec la commande #{lb build}#
-
-code{
-
- # lb build
-
-}code
-
-Quand la création de l'image est finie, un fichier #{binary.img}# doit être
-présent dans le répertoire courant.
-
-2~using-usb-hdd-image Utiliser une image USB/HDD
-
-L'image binaire générée contient une partition VFAT et le chargeur de
-démarrage syslinux, prêtes à être écrites directement sur une clé USB. Comme
-l'utilisation d'une image USB/HDD est juste comme l'utilisation d'une image
-ISO hybride sur USB, suivez les instructions {Utiliser une image live ISO
-hybride}#using-iso-hybrid, à l'exception du nom de fichier #{binary.img}# en
-lieu de #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Test d'une image USB/HDD avec Qemu
-
-D'abord, installer QEMU comme décrit ci-dessus dans {Test d'une image ISO
-avec QEMU}#testing-iso-with-qemu. Ensuite, exécutez #{kvm}# ou #{qemu}#,
-selon la version de vos besoins du système hôte, précisant #{binary.img}#
-comme le premier disque dur.
-
-code{
-
- $ kvm -hda binary.img
-
-}code
-
-3~using-usb-extra-space Utilisation de l'espace disponible sur une clé USB
-
-Pour utiliser l'espace libre restant après avoir copié #{binary.img}# sur
-une clé USB, utilisez un outil de partitionnement tels que #{gparted}# ou
-#{parted}# afin de créer une nouvelle partition sur la clé. La première
-partition sera utilisée par le système Debian Live.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-Après la partition est créée, où #{${PARTITION}}# est le nom de la
-partition, tel que #{/dev/sdb2}#, vous devez créer un système de fichiers
-sur elle. Un choix possible serait ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Remarque: Si vous voulez utiliser l'espace supplémentaire avec Windows,
-apparemment cet OS ne peut normalement pas accéder à n'importe quel
-partition, mais la première. Certaines solutions à ce problème ont été
-discutés sur notre {liste de diffusion}#contact, mais il semble qu'il n'y a
-pas de réponses faciles.
-
-*{Rappelez-vous: Chaque fois que vous installez une nouvelle binary.img sur la clé, toutes les données sur la clé seront perdues parce que la table de partition est écrasé par le contenu de l'image, vous devez sauvegarder votre partition supplémentaire d'abord la restaurer à nouveau après la mise à jour du live image.}*
-
-2~building-netboot-image Construction d'une image netboot
-
-La séquence de commandes suivante va créer une image NetBoot de base
-contenant le système Debian standard sans X.org. Elle peur être démarrée sur
-le réseau.
-
-Remarque: Si vous avez réalisé tous les exemples précédents, vous aurez
-besoin de nettoyer votre répertoire de travail avec la commande #{lb
-clean}#:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Exécutez la commande comme suit pour configurer votre image pour démarrer
-sur le réseau:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-Contrairement à les images ISO et USB/HDD netbooting ne serve pas l'image du
-système de fichiers pour le client, afin que les fichiers doivent être
-servis via NFS. Les options #{--net-root-path}# et #{--net-root-server}#
-spécifien l'emplacement et le serveur, respectivement, du serveur NFS sur
-lequel l'image système de fichiers sera situé au moment du
-démarrage. Assurez-vous que ce sont mis à des valeurs appropriées pour votre
-réseau et serveur.
-
-Maintenant construire l'image avec la commande #{lb build}#
-
-code{
-
- # lb build
-
-}code
-
-Dans un démarrage réseau, le client exécute un petit morceau de logiciel qui
-réside habituellement sur l'EPROM de la carte Ethernet. Ce programme envoie
-une requête DHCP pour obtenir une adresse IP et les informations sur ce
-qu'il faut faire ensuite. Typiquement, la prochaine étape est obtenir un
-chargeur de démarrage de niveau supérieur via le protocole TFTP. Cela
-pourrait être pxelinux, GRUB, ou démarrer directement à un système
-d'exploitation comme Linux.
-
-Par exemple, si vous décompressez le fichier généré #{binary-net.tar.gz}#
-dans le répertoire #{/srv/debian-live}#, vous trouverez l'image du système
-de fichiers dans #{live/filesystem.squashfs}# et le kernel, initrd et le
-chargeur de démarrage pxelinux dans #{tftpboot/debian-live/i386}#.
-
-Nous devons maintenant configurer trois services sur le serveur pour activer
-netboot: le serveur DHCP, serveur TFTP et le serveur NFS.
-
-3~ Serveur DHCP
-
-Nous devons configurer le serveur DHCP de notre réseau pour être sûr de
-donner une adresse IP au système client netboot, et pour annoncer
-l'emplacement du chargeur de démarrage PXE.
-
-Voici un exemple source d'inspiration, écrit pour le serveur ISC DHCP
-#{isc-dhcp-server}# dans le fichier de configuration
-#{/etc/dhcp/dhcpd.conf}#:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ Serveur TFTP
-
-Cela sert le kernel et le ramdisk initial pour le système au moment de
-l'exécution.
-
-Vous devriez installer le paquet tftpd-hpa. Il peut servir tous les fichiers
-contenus dans un répertoire racine, d'habitude #{/srv/tftp}#. Pour le
-laisser servir des fichiers dans #{/srv/debian-live/tftpboot}#, exécuter
-comme utilisateur root la commande suivante:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-et remplissez le nuveau répertoire du serveur tftp
-
-3~ Serveur NFS
-
-Une fois l'ordinateur hôte a téléchargé et démarré un kernel Linux et chargé
-son initrd, il va essayer de monter l'image du système de fichiers live via
-un serveur NFS.
-
-Vous devez installer le paquet #{nfs-kernel-server}#.
-
-Ensuite, rendre l'image du système de fichiers disponible via NFS en
-ajoutant une ligne comme la suivante #{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-et dire au serveur NFS sur cette exportation avec la commande suivante:
-
-code{
-
- # exportfs -rv
-
-}code
-
-Mise en place ces trois services peut être un peu délicat. Vous pourriez
-avoir besoin de patience pour obtenir que tous travaillent ensemble. Pour
-plus d'informations, consultez le wiki syslinux à
-http://syslinux.zytor.com/wiki/index.php/PXELINUX ou la section Debian
-Installer Manual's TFTP Net Booting à
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. Ils pourraient
-aider parce que leurs processus sont très semblables.
-
-3~ Guide pratique pour expérimenter avec une image Netboot
-
-La création d'images NetBoot est facile avec la magie de live-build, mais
-les essais des images sur des machines physiques peuvent prendre vraiment
-beaucoup de temps.
-
-Afin de rendre notre vie plus facile, nous pouvons utiliser la
-virtualisation. Il ya deux solutions.
-
-3~ Qemu
-
-_* Installer #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Èditer #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Obtenir, ou construire un #{grub-floppy-netboot}# (dans le svn).
-
-Lancer #{qemu}# avec "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Installer VMWare Player (édition "free as in beer")
-
-_* Créer un répertoire PXETester, et créer un fichier texte appelé
-#{pxe.vwx}# à l'intérieur
-
-_* Collez ce texte à l'intérieur:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* Vous pouvez jouer avec ce fichier de configuration (par exemple, changer
-la limite de mémoire à 256)
-
-_* Double-cliquez sur ce fichier (ou exécuter VMware Player et sélectionnez
-ce fichier).
-
-_* Lors de l'exécution presse l'espace si cette question étrange arrive ...
diff --git a/manual/fr/user_customization-binary.ssi b/manual/fr/user_customization-binary.ssi
deleted file mode 100644
index a235165..0000000
--- a/manual/fr/user_customization-binary.ssi
+++ /dev/null
@@ -1,38 +0,0 @@
-B~ Personnalisation de l'image binaire
-
-1~customizing-binary Personnalisation de l'image binaire
-
-2~ Chargeur de démarrage
-
-live-build utilise syslinux comme chargeur de démarrage par défaut, qui est
-configuré par défaut pour pauser indéfiniment à son écran splash. Pour
-régler cela, vous pouvez passer #{--syslinux-timeout TIMEOUT}# à #{lb
-config}#. La valeur est spécifiée en unités de secondes. Une valeur 0 (zéro)
-désactive le délai complètement. Pour plus d'informations s'il vous plaît
-voir syslinux(1).
-
-2~ Métadonnées ISO
-
-En créant une image binaire ISO9660, vous pouvez utiliser les options
-suivantes pour ajouter différentes métadonnées textuelles pour votre
-image. Cela peut vous aider à facilement identifier la version ou la
-configuration d'une image sans la démarrer.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: Cela devrait décrire
-l'application qui sera sur l'image. La longueur maximale de ce champ est de
-128 caractères.
-
-_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: Cela devrait décrire le
-préparateur de l'image, généralement avec certains détails de contact. Le
-défaut de cette option est la version de live-build que vous utilisez, ce
-qui peut faciliter le débogage plus tard. La longueur maximale de ce champ
-est de 128 caractères.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: Ce doit décrire l'éditeur de
-l'image, généralement avec certains détails de contact. La longueur maximale
-de ce champ est de 128 caractères.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: Cela devrait spécifier l'ID de
-volume de l'image. Il est utilisé comme une étiquette visible par
-l'utilisateur sur certaines plateformes comme Windows et Apple Mac OS. La
-longueur maximale de ce champ est de 128 caractères.
diff --git a/manual/fr/user_customization-contents.ssi b/manual/fr/user_customization-contents.ssi
deleted file mode 100644
index 8d8a735..0000000
--- a/manual/fr/user_customization-contents.ssi
+++ /dev/null
@@ -1,164 +0,0 @@
-:B~ Personnalisation des contenus
-
-1~customizing-contents Personnalisation des contenus
-
-Ce chapitre aborde affiner la personnalisation du contenu du système live
-delà du simple choix des paquets à inclure. Les includes vous permettent
-d'ajouter ou de remplacer des fichiers arbitraires à votre image Debian
-Live, les hooks vous permettent d'exécuter des commandes arbitraires à
-différentes étapes de la construction et au démarrage, et la
-préconfiguration (preseeding) vous permet de configurer les paquets quand
-ils sont installés en fournissant des réponses aux questions debconf .
-
-2~ Includes
-
-Bien qu'idéalement un système Debian Live comprendrait les fichiers
-entièrement fournis par les paquets Debian non modifiés, on convient parfois
-de fournir ou de modifier certains contenus par le biais de fichiers. Avec
-les includes, il est possible d'ajouter (ou remplacer) des fichiers
-arbitraires à votre image live de Debian. live-build prévoit trois
-mécanismes de leur utilisation:
-
-_* Chroot local includes: Ils vous permettent d'ajouter ou remplacer des
-fichiers sur le système de fichiers chroot/Live. S'il vous plaît voir
-{Live/chroot local includes}#live-chroot-local-includes pour plus
-d'informations.
-
-_* Binary local includes: Ils vous permettent d'ajouter ou de remplacer des
-fichiers dans l'image binaire. S'il vous plaît voir {Binary local
-includes}#binary-local-includes pour plus d'informations.
-
-_* Binary includes: Ils vous permettent d'ajouter ou remplacer des fichiers
-spécifiques de Debian dans l'image binaire, comme les modèles et les
-répertoires d'outils. S'il vous plaît voir {Binary includes}#binary-includes
-pour plus d'informations.
-
-S'il vous plaît voir {Termes}#terms pour plus d'informations sur la
-distinction entre les images "Live" et "binaire".
-
-3~live-chroot-local-includes Live/chroot local includes
-
-Chroot local includes peuvent être utilisés pour ajouter ou remplacer des
-fichiers dans le système de fichiers chroot/Live afin qu'ils puissent être
-utilisés dans le système Live. Une utilisation typique est de peupler le
-répertoire du squelette de l'utilisateur (#{/etc/skel}#) utilisé par le
-système live pour créer le répertoire home de l'utilisateur Live. Une autre
-est de fournir des fichiers de configuration qui peuvent être simplement
-ajoutés ou remplacés à l'image sans traitement, voir {Live/chroot local
-hooks}#live-chroot-local-hooks si le traitement est nécessaire.
-
-Pour inclure des fichiers, il suffit de les ajouter à votre répertoire
-#{config/chroot_local-includes}#. Ce répertoire correspond au répertoire
-racine (#{/}#) du système live. Par exemple, pour ajouter un fichier
-#{/var/www/index.html}# dans le système live, utilisez:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/var/www
- $ cp /path/to/my/index.html config/chroot_local-includes/var/www
-
-}code
-
-Votre configuration aura alors le schéma suivant:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Chroot local includes sont installés après l'installation de paquets de
-sorte que les fichiers installés par les paquets sont écrasés.
-
-3~binary-local-includes Binary local includes
-
-Pour inclure des matériels tels que des documents ou des vidéos sur le
-système de fichiers des supports, afin qu'il soit accessible dès l'insertion
-du support sans avoir à démarrer le système live, vous pouvez utiliser
-binary local includes. Cela fonctionne de façon similaire aux chroot local
-includes. Par exemple, supposons que les fichiers #{~/video_demo.*}# sont
-des vidéos de démonstration du système live décrit par et lié par une page
-d'index HTML. Copiez simplement le matériel à
-#{config/binary_local-includes/}# comme suit:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-Ces fichiers apparaissent maintenant dans le répertoire racine du support
-live.
-
-3~binary-includes Binary includes
-
-live-build a certains fichiers standard (comme la documentation) qui sera
-inclus dans la configuration par défaut sur tous les supports live. Ceci
-peut être désactivé avec:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-Sinon, le matériel sera installé par live-build dans #{/includes/}# par
-défaut sur le système de fichiers du support, ou bien vous pouvez spécifier
-un autre chemin avec
-
-2~ Hooks
-
-Les hooks permettent à les commandes être exécutées dans les étapes chroot
-et binaire de la construction afin de personnaliser l'image.
-
-3~live-chroot-local-hooks Live/chroot local hooks
-
-Pour exécuter des commandes à l'étape chroot, créer un script hook contenant
-les commandes dans le répertoire #{config/chroot_local-hooks}#. Le hook
-s'exécutera dans le chroot après le reste de votre configuration chroot a
-été appliquée, donc n'oubliez pas de vous assurer que votre configuration
-inclut tous les paquets et les fichiers que votre hook a besoin pour
-fonctionner. Voir les exemples de scripts chroot hook pour diverses tâches
-courantes de personnalisation chroot fournis dans
-#{/usr/share/live/build/examples/hooks}# que vous pouvez copier ou symlink
-pour les utiliser dans votre propre configuration.
-
-3~boot-time-hooks Hooks au moment du démarrage
-
-Pour exécuter des commandes au moment du démarrage, vous pouvez fournir
-live-config hooks comme expliqué dans la section "Personnalisation" de sa
-page de manuel. Examiner les hooks de live-config fournis dans
-#{/lib/live/config/}#, en notant les numéros de séquence. Puis fournir votre
-propre hook préfixée avec un numéro de séquence appropriée, soit comme un
-chroot local include dans #{config/chroot_local-includes/lib/live/config/}#,
-ou comme un paquet personnalisé tel que discuté dans {Installation des
-paquets modifiés ou de tiers}#installing-modified-or-third-party-packages.
-
-3~ Binary local hooks
-
-Pour exécuter des commandes à l'étape binaire, créer un script hook
-contenant les commandes dans #{config/binary_local-hooks}#. Le hook sera
-exécuté après toutes les autres commandes binaires sont exécutées, mais
-avant binary_checksums, les dernièrs commandes binaires. Les commandes de
-votre hook ne s'exécutent pas dans le chroot, afin de prendre soin de ne pas
-modifier les fichiers en dehors de l'arbre de construction, ou vous pourriez
-endommager votre système de construction! Voir les exemples de scripts hook
-binaires pour diverses tâches courantes de personnalisation binaires fournis
-dans #{/usr/share/live/build/examples/hooks}# que vous pouvez copier ou
-symlink pour les utiliser dans votre propre configuration.
-
-2~ Préconfigurer questions de debconf
-
-Les fichiers dans le répertoire #{config/chroot_local-preseed}# sont
-considérés comme des fichiers de préconfiguration debconf et sont installés
-par live-build en utilisant #{debconf-set-selections}#.
-
-Pour plus d'informations sur debconf, s'il vous plaît voir debconf(7) dans
-le paquet #{debconf}#.
diff --git a/manual/fr/user_customization-installer.ssi b/manual/fr/user_customization-installer.ssi
deleted file mode 100644
index 65afc6c..0000000
--- a/manual/fr/user_customization-installer.ssi
+++ /dev/null
@@ -1,91 +0,0 @@
-:B~ Personnalisation de l'installateur Debian
-
-1~customizing-installer Personnalisation de l'installateur Debian
-
-Les images du système Debian Live peuvent être intégrées à l'installateur
-Debian. Il y a un certain nombre de différents types d'installation, variant
-en ce qui est inclus et comment fonctionne l'installateur.
-
-S'il vous plaît noter l'utilisation prudente des lettres majuscules pour
-désigner «l'Installateur Debian» dans cette section - lorsqu'il est utilisé
-comme cela, nous faisons explicitement référence à l'installateur officiel
-pour le système Debian, rien d'autre. On le voit souvent abrégé en «d-i».
-
-2~ Types de l'installateur Debian
-
-Les trois principaux types de programme d'installation sont:
-
-*{Installateur Debian «Régulière»}*: C'est une image de Debian Live normale avec un noyau séparé et initrd qui (lorsqu'il est sélectionné à partir du chargeur de démarrage approprié) se lance dans une instance d'installateur Debian standard, exactement comme si vous aviez téléchargé une image CD de Debian et la démarré.
-
-Sur ces images, Debian est installé par l'extraction et l'installation de
-paquets .deb à l'aide de #{debootstrap}# ou #{cdebootstrap}#, Depuis des
-supports locaux ou à partir du réseau basé sur le réseau, résultant en un
-système Debian standard en cours d'installation sur le disque dur.
-
-Tout ce processus peut être préconfiguré et personnalisé dans un certain
-nombre de façons, voir les pages correspondantes dans le manuel de
-l'Installateur Debian pour plus d'informations. Une fois que vous avez un
-fichier de préconfiguration qui fonctionne live-build peut automatiquement
-le mettre à l'image et l'activer pour vous.
-
-*{Installateur Debian "Live" }*: C'est une image de Debian Live avec un noyau séparé et initrd qui (lorsqu'il est sélectionné à partir du chargeur de démarrage approprié) se lance dans une instance de l'installateur Debian.
-
-L'installation se poursuit de manière identique à l'installation "régulière"
-décrite ci-dessus, mais à l'étape de l'installation des paquets, au lieu
-d'utiliser #{debootstrap}# pour aller chercher et installer des paquets,
-l'image du système de fichiers live est copiée vers la cible. Ce résultat
-est obtenu avec un udeb spécial appelé «live-installer».
-
-Après cette étape, l'installateur Debian se poursuit normalement, en
-installant et configurant des éléments tels que chargeurs de démarrage et
-les utilisateurs locaux, etc
-
-Remarque: Pour soutenir les deux entrées installateur normal et live dans le
-chargeur de démarrage du même support live, vous devez désactiver
-«live-installer» en préconfiguration #{live-installer/enable=false}#.
-
-*{Installateur Debian "de bureau"}*: Indépendamment du type d'installateur Debian inclus, #{d-i}# peut être lancé depuis le Bureau en cliquant sur une icône. C'est facile à utiliser dans certaines situations. Afin de faire usage de cela, le paquet debian-installer-launcher doit être inclus.
-
-Notez que par défaut, live-build n'inclut pas les images de l'installateur
-Debian dans les images, il doit être spécifiquement activée avec #{lb
-config}#. Aussi, s'il vous plaît noter que pour que l'installateur "de
-bureau" fonctionne le noyau du système live doit correspondre au noyau que
-#{d-i}# utilise pour l'architecture spécifiée. Par exemple:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Personnalisation de l'installateur Debian par préconfiguration
-
-Comme décrit dans le Debian Installer Manual, Appendix B at
-http://www.debian.org/releases/stable/i386/apb.html,
-"La préconfiguration est une façon de donner des réponses aux questions
-posées durant le processus d'installation, sans avoir à entrer manuellement
-les réponses alors que l'installation est en marche. Cela permet
-d'automatiser entièrement la plupart des types d'installation et propose
-même quelques fonctionnalités ne sont pas disponibles pendant les
-installations normales ». Ce type de personnalisation se fait mieux avec
-live-build en plaçant la configuration dans un fichier #{preseed.cfg}#
-inclus dans #{config/binary_debian-installer/}#. Par exemple, pour
-préconfigurer les paramètres régionaux pour #{en_US}#:
-
-code{
-
- $ echo "d-i debian-installer/locale string en_US" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Personnalisation de contenu pour l'Installateur Debian
-
-Pour des fins expérimentales ou de débogage, vous pouvez inclure paquets
-udeb #{d-i}# construits localement. Les placer dans
-#{config/binary_local-udebs/}# pour les inclure dans l'image. Fichiers
-supplémentaires ou de remplacement et répertoires peuvent être inclus dans
-l'initrd de l'installateur ainsi, d'une manière similaire à {Live/chroot
-local includes}#live-chroot-local-includes en plaçant le matériau dans
-#{config/binary_debian-installer-includes/}#.
diff --git a/manual/fr/user_customization-overview.ssi b/manual/fr/user_customization-overview.ssi
deleted file mode 100644
index c71f69c..0000000
--- a/manual/fr/user_customization-overview.ssi
+++ /dev/null
@@ -1,83 +0,0 @@
-:B~ Personnalisation des contenus
-
-1~customization-overview Vue d'ensemble de la personnalisation
-
-Ce chapitre donne un aperçu des diverses façons dont vous pouvez
-personnaliser un système Debian Live.
-
-2~ Configuration pendant la construction vs. le démarrage
-
-Les options de configuration d'un système live sont divisés en options au
-moment de la construction, ces options sont appliqués pendant la création et
-des options au moment du démarrage, qui sont appliqués au moment du
-démarrage. Les options au moment du démarrage sont divisées en celles qui
-surviennent au début, appliquées par le paquet live-boot, et ceux qui
-arrivent plus tard, appliquées par live-config. Toute option de démarrage
-peut être modifiée par l'utilisateur en le spécifiant à l'invite de
-démarrage. L'image peut également être construite avec les paramètres de
-démarrage par défaut et alors les utilisateurs peuvent normalement démarrer
-directement au système live sans spécifier aucune option lorsque toutes les
-valeurs par défaut sont appropriées. En particulier, l'argument #{lb
---bootappend-live}# se compose de toutes les options de ligne de commande du
-kernel par défaut pour le système live, comme la persistance, claviers, ou
-de fuseau horaire. Voir {Personnalisation des paramètres régionaux et la
-langue}#customizing-locale-and-language, par exemple.
-
-Les options de configuration pendant la construction sont décrites dans les
-pages de manuel pour live-boot and live-config. Bien que les paquets
-live-boot et live-config sont installés dans le système live que vous
-construisez, il est recommandé que vous les installez aussi sur votre
-système de construction pour référence facile lorsque vous travaillez sur
-votre configuration. On peut faire ça sans danger, car aucun des scripts
-contenus dans eux sont exécutés à moins que le système est configuré comme
-un système live.
-
-2~stages-of-the-build Étapes de la construction
-
-Le processus de construction est divisé en étapes, avec des
-personnalisations différentes appliquées dans l'ordre dans chaque étape. La
-première étape à exécuter est l'étape *{bootstrap}*. C'est la phase initiale
-de peupler le répertoire chroot avec des paquets pour faire un système
-Debian de base. Il est suivi par l'étape *{chroot}*, qui complète la
-construction du répertoire chroot, le peuplant de tous les paquets listés
-dans la configuration, ainsi que tout autre matériel. La plupart de
-personnalisation de contenu se produit à ce stade. La dernière étape de la
-préparation de l'image live est l'étape *{binary}*, qui construit une image
-démarrable, en utilisant le contenu du répertoire chroot pour construire le
-système de fichiers racine pour le système Live, et dont l'installateur et
-tout autre matériel supplémentaire sur les supports objectif en dehors du
-système de fichiers du système live. Après l'image live est construite, s'il
-est activé, l'archive source est construit dans l'étape *{source}*.
-
-Dans chacune de ces étapes, il ya une séquence particulière dans laquelle
-les commandes sont appliquées. Ce sont disposées de telle manière à assurer
-que les personnalisations peuvent être superposées de manière
-raisonnable. Par exemple, dans l'étape *{chroot}*, preseeds sont appliqués
-avant tous les paquets sont installés, les paquets sont installés avant tout
-les fichiers localement inclus ou les patches sont appliqués, et les hooks
-sont exécutés plus tard, après que tous les matériaux sont en place.
-
-2~ Supplément lb config avec des fichiers
-
-Bien que #{lb config}# crée une configuration du squelette dans le
-répertoire config/, pour accomplir vos objectifs, vous pourriez avoir besoin
-de fournir des fichiers supplémentaires dans les sous-répertoires de
-config/. Selon l'endroit où les fichiers sont stockés dans la configuration,
-ils peuvent être copiés dans le système de fichiers du système live ou dans
-le système de fichiers de l'image binaire, ou peut fournir configurations du
-système au moment de la construction qui serait lourd de passer comme
-options de la ligne de commande. Vous pouvez inclure des choses telles que
-des listes personnalisées de paquets, art personnalisé, ou des scripts hook
-à exécuter, soit au temps de construction ou au moment du démarrage,
-augmentant la flexibilité déjà considérable de debian-live avec code de
-votre choix.
-
-2~ Tâches de personnalisation
-
-Les chapitres suivants sont organisés par les types des tâches de
-personnalisation que les utilisateurs effectuent généralement:
-{Personnalisation de l'installation de
-paquets}#customizing-package-installation, {Personnalisation des
-contenus}#customizing-contents et {Personnalisation des paramètres régionaux
-et la langue}#customizing-locale-and-language couvrent quelques choses que
-vous pourriez vouloir faire.
diff --git a/manual/fr/user_customization-packages.ssi b/manual/fr/user_customization-packages.ssi
deleted file mode 100644
index 9115244..0000000
--- a/manual/fr/user_customization-packages.ssi
+++ /dev/null
@@ -1,628 +0,0 @@
-:B~ Personnalisation de l'installation de paquets
-
-1~customizing-package-installation Personnalisation de l'installation de
-paquets
-
-La personnalisation la plus fondamentale d'un système Debian Live peut-être
-la sélection de paquets à inclure dans l'image. Ce chapitre vous guide tout
-au long des différents options dans certains moments de la construction pour
-personnaliser l'installation des paquets de live-build. Le plus large choix
-influençant les paquets qui sont disponibles pour l'installation dans
-l'image sont les zones de distribution et archive areas. Afin de garantir
-des vitesses de téléchargement décent, vous devez choisir un miroir de
-distribution proche. Vous pouvez également ajouter vos propres référentiels
-pour les backports, paquets expérimentaux ou personnalisés, ou inclure des
-paquets directement en tant que fichiers. Vous pouvez définir vos propres
-listes de paquets à inclure, utiliser des listes prédéfinies de live-build,
-utiliser tâches #{tasksel}#, ou une combinaison des trois. Enfin, un certain
-nombre d'options donnent un certain contrôle sur apt, ou si vous préférez,
-aptitude, au moment de la construction quand les paquets sont
-installés. Vous pouvez trouver ces très pratique si vous utilisez un proxy,
-vous voulez désactiver l'installation des paquets recommandés pour
-économiser l'espace, ou avez besoin de contrôler quels versions des paquets
-sont installés via APT pinning, pour n'en nommer quelques possibilités.
-
-2~ Sources des paquets
-
-3~ Distribution, archive areas et mode
-
-La distribution que vous choisissez a le plus large impact sur les paquets
-qui sont disponibles à inclure dans votre image live. Indiquez le nom de
-code, qui est par défaut #{squeeze}# pour la version de live-build dans
-Squeeze. Toute distribution actuelle dans l'archive Debian peut être
-spécifié par son nom de code ici. (Voir {Termes}#terms pour plus de
-détails.) L'option #{--distribution}# non seulement influence la source des
-paquets dans l'archive, mais aussi dit #{live-build}# comme it doit
-construire chaque distribution supportée. Par exemple, pour construire
-contre *unstable*, Sid, précisez:
-
-code{
-
- $ lb config --distribution sid
-
-}code
-
-Dans l'archive de distribution, les «archive areas» sont les principales
-divisions de l'archive. Dans Debian, ce sont #{main}#, #{contrib}# et
-#{non-free}#. Seulement #{main}# contient des logiciels qui font partie de
-la distribution Debian, donc qui est la valeur par défaut. Une ou plusieurs
-valeurs peuvent être spécifiées, par exemple
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Support expérimental est disponible pour certains dérivés de Debian par
-l'option #{--mode}#. L'option #{debian}# est définie par défaut, même si
-vous êtes en créant sur un système non-Debian. Si vous spécifiez #{--mode
-ubuntu}# ou #{--mode emdebian}#, les noms de distribution et des archive
-areas pour les dérivés spécifiés sont supportés au lieu de ceux de Debian.
-Le mode modifie également le comportement de live-build en fonction des
-dérivés.
-
-*{Remarque:}* Les projets pour lesquels ces modes ont été ajoutés sont principalement responsables de aider les utilisateurs de ces options. Le projet Debian Live, à son tour, fournit un support de développement sur une base des meilleurs efforts seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développé ou supporté nous-mêmes.
-
-3~ Miroirs de distribution
-
-L'archive Debian est répliqué à travers un large réseau de miroirs autour du
-monde pour que les gens dans chaque région peuvent choisir un miroir proche
-avec la meilleur vitesse de téléchargement. Chacune des options
-#{--mirror-*}# qui régit quel miroir de distribution est utilisée à
-différents stades de la construction. Rappelez-vous de {Etapes de la
-construction}#stages-of-the-build que l'étape *bootstrap* c'est quand le
-chroot est initialement peuplée par debootstrap avec un système minimal, et
-l'étape *chroot* c'est quand le chroot utilisé pour construire le système de
-fichiers du système live est construit. Ainsi, les commutateurs des miroirs
-correspondants sont utilisées pour ces étapes, et plus tard, dans le
-*binary* stade les valeurs #{--mirror-binary}# et
-#{--mirror-binary-security}# sont utilisées, remplaçant tout miroir utilisé
-dans une étape antérieure.
-
-3~distribution-mirrors-build-time Miroirs de distribution utilisés au temps
-de construction
-
-Pour définir les miroirs de distribution utilisés au temps de construction
-pour pointer vers un miroir local, il suffit de fixer #{--mirror-bootstrap}#
-et #{--mirror-chroot-security}# comme suit.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-Le miroir chroot, spécifiée par #{--mirror-chroot}#, par défaut, c'est la
-valeur #{--mirror-bootstrap}#.
-
-3~ Miroirs de distribution utilisés au moment de l'exécution
-
-Les options #{--mirror-binary*}# régissent les miroirs de distribution
-placés dans l'image binaire. Ils peuvent être utilisés pour installer des
-paquets supplémentaires lors de l'exécution du système live. Les valeurs par
-défaut emploient #{cdn.debian.net}#, un service qui choisit un miroir
-géographiquement proche basé sur le numéro IP de l'utilisateur. C'est un
-choix approprié lorsque vous ne pouvez pas prédire quel miroir sera mieux
-pour tous vos utilisateurs. Ou vous pouvez spécifier vos propres valeurs,
-comme indiqué dans l'exemple ci-dessous. Une image construite avec cette
-configuration seulement serait approprié pour les utilisateurs sur un réseau
-où "#{mirror}#" est accessible.
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Référentiels additionnels
-
-Vous pouvez ajouter plus de référentiels, élargir vos choix de paquets
-au-delà ceux disponibles dans votre distribution objectif. Il peut être, par
-exemple, pour backports, expérimentaux ou des paquets personnalisés. Pour
-configurer des référentiels supplémentaires, créer les fichiers
-#{config/chroot_sources/your-repository.chroot}#, et/ou
-#{config/chroot_sources/your-repository.binary}#. Comme avec les options
-#{--mirror-*}#, elles gouvernent les référentiels utilisés dans l'étape
-*chroot* lors de la construction de l'image, et dans l'étape *binaire*,
-c'est à dire pour une utilisation au moment de l'exécution du système live.
-
-Par exemple, #{config/chroot_sources/live.chroot}# vous permet d'installer
-des paquets du référentiel des instantanés debian live au moment de la
-construction du système live.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-Si vous ajoutez la même ligne à #{config/chroot_sources/live.binary}#, le
-référentiel sera ajouté à le répertoire #{/etc/apt/sources.list.d/}# de
-votre système live.
-
-Si ces fichiers existent, ils seront sélectionnés automatiquement.
-
-Vous devriez également mettre la clé GPG utilisée pour signer le référentiel
-dans fichiers #{config/chroot_sources/your-repository.{binary,chroot}.gpg}#
-
-*{Remarque:}* certains référentiels de paquets préconfigurés sont disponibles pour une sélection facile grâce à l'option #{--repository}#, par exemple pour permettre des instantanés live, une simple commande suffit pour l'activer:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Choisir les paquets à installer
-
-Il y a un certain nombre de façons de choisir quels paquets live-build va
-installer dans votre image, couvrant une variété de besoins différents. Vous
-pouvez tout simplement nommer les paquets individuels à installer, que ce
-soit avec l'option #{--packages}# pour quelques paquets, ou dans une liste
-de paquets pour un grand nombre de paquets. Vous pouvez également choisir
-grandes listes prédéfinies de paquets, ou utilisez des tâches APT. Et enfin,
-vous pouvez placer paquets dans votre arbre #{config/}# qui est bien adapté
-aux essais de nouveaux paquets ou expérimentaux avant qu'ils ne soient
-disponibles à partir d'un référentiel.
-
-3~ Choisir un certain nombre de paquets
-
-Si le nombre de paquets ajoutée est petit il suffit de spécifier
-#{--packages}#. Par exemple:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-Le comportement de live-build pour spécifier un paquet qui n'existe pas est
-déterminé par votre choix de l'utilité APT. Voir {Choisir apt ou
-aptitude}#choosing-apt-or-aptitude pour plus de détails.
-
-Si vous avez besoin de spécifier un grand nombre de paquets à installer ou
-vous avez besoin de flexibilité en ce qui concerne les paquets à installer,
-utilisez des listes de paquets tel que discuté dans la section suivante,
-{Listes de paquets}#package-lists.
-
-3~package-lists Listes de paquets
-
-Les listes de paquets sont un excellent moyen d'exprimer quels paquets
-doivent être installés. La syntaxe de la liste supporte les fichiers inclus
-et sections conditionnelles qui les rend facile de construire à partir
-d'autres listes et de les adapter pour une utilisation dans configurations
-multiples. Vous pouvez utiliser des listes de paquets prédéfinies, offrant
-une sélection modulaire de paquets provenantes de chacun des environnements
-de bureau majeurs et certaines listes de but spécial, ainsi que les autres
-listes standard sont basées sur elles. Vous pouvez également fournir votre
-propre liste de paquets, ou utiliser une combinaison des deux.
-
-3~ Listes de paquets prédéfinies
-
-La façon la plus simple d'utiliser des listes consiste à spécifier une ou
-plusieurs listes prédéfinies avec la option #{--packages-lists}#. Par
-exemple:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-En plus de ces listes, live-build supporte quatre listes de paquets
-virtuels: #{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# et
-#{xfce-desktop}#, chacun d'entre eux offrent une sélection plus grande de
-paquets qui correspond à valeurs par défaut de l'installateur Debian pour
-ces environnements de bureau. Voir {Tâches de bureau et de la
-langue}#desktop-and-language-tasks pour plus de détails.
-
-*{Remarque:}* Les images préconstruites GNOME, KDE, LXDE et XFCE disponibles pour téléchargement à http://live.debian.net sont construites en utilisant les listes virtuels correspondantes #{*-desktop}#.
-
-L'emplacement par défaut pour les fichiers liste sur votre système est
-#{/usr/share/live/build/lists/}#. Pour déterminer les paquets dans une liste
-donnée, lire le fichier correspondant, en accordant une attention aux
-fichiers inclus et les conditionnels tels que décrits dans les sections
-suivantes.
-
-3~ Listes de paquets locaux
-
-Vous pouvez compléter ou remplacer entièrement les listes fournies en
-utilisant listes de paquets locaux stockées dans
-#{config/chroot_local-packageslists/}#.
-
-Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un
-suffixe #{.list}# pour être traitées. Les listes locaux de paquets ont
-toujours priorité sur les listes de paquets distribués avec live-build. Cela
-peut causer des effets indésirables, nous recommandons donc d'utiliser des
-noms uniques pour listes de paquets locaux.
-
-3~ Listes locaux de paquets binaires
-
-Dans le cas où vous voulez inclure certains paquets .deb dans #{pool/}# de
-votre support live (sans les installer sur l'image live) vous pouvez avoir
-besoin d'utiliser des listes à l'aide de listes locaux de paquets binaires
-stockées dans #{config/binary_local-packageslists/}#. Ces supports peuvent
-être utilisés comme une image d'installation de Debian personnalisés pour
-les installations hors-ligne.
-
-Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un
-suffixe #{.list}# pour être traitées.
-
-3~ Extension d'un liste de paquets fournis à l'aide de «includes»
-
-Les listes de paquets qui sont incluses avec live-build font un grand usage
-des «includes». Reportez-vous à ceux-ci dans le répertoire
-#{/usr/share/live/build/lists/}#, car ils servent d'exemples pour savoir
-comment écrire vos propres listes.
-
-Par exemple, pour faire une liste qui comprend la liste prédéfinie
-#{gnome}#, plus iceweasel, créer
-#{config/chroot_local-packageslists/mygnome.list}# avec le contenu suivant:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Utilisant des conditionnels dans les listes de paquets
-
-Toutes les variables de configuration de live-build stockées dans
-#{config/*}# (sans le préfixe #{LB_}#) peuvent être utilisés dans
-instructions conditionnelles dans les listes de paquets. Généralement, cela
-signifie une option #{lb config}# majuscule et avec tirets changées en
-caractères de soulignement. Mais en pratique, c'est seulement ceux qui
-influencent lasélection des paquets qui font sens, comme #{DISTRIBUTION}#,
-#{ARCHITECTURE}# ou #{ARCHIVE_AREAS}#.
-
-Par exemple, pour installer #{ia32-libs}# si la #{--architecture amd64}# est
-spécifié:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-Vous pouvez tester pour un certain nombre de valeurs, par exemple pour
-installer #{memtest86+}# si #{--architecture i386}# ou #{--architecture
-amd64}# est spécifié:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-Vous pouvez également tester contre des variables qui peuvent contenir plus
-d'une valeur, par exemple pour installer #{vrms}# si #{contrib}# ou
-#{non-free}# est spécifié via #{--archive-areas}#:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-Un conditionnel peut entourer une directive #{#include}#:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-L'imbrication des conditionnels n'est pas supportée.
-
-3~ Tâches
-
-L'installateur Debian offre l'utilisateur le choix d'un certain nombre de
-listes présélectionnées de paquets, chacun centré sur un type particulier de
-système ou d'une tâche pour laquelle un système peut être utilisé, comme
-«environnement de bureau graphique», «serveur de messagerie» ou
-«portable». Ces listes sont appelés «tâches» et sont supportés par APT à
-travers l'option «Task:» Vous pouvez spécifier une ou plusieurs tâches en
-live-build via l'option #{--tasks}#, comme dans l'exemple ci-dessous.
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-Les tâches principales disponibles dans l'installateur Debian peuvent être
-listés avec #{tasksel --list-tasks}# dans le système live. Le contenu de
-n'importe quelle tâche, y compris ceux non inclus dans cette liste, peuvent
-être examinées avec #{tasksel --task-packages}#.
-
-3~desktop-and-language-tasks Tâches de bureau et de la langue
-
-Les tâches de bureau et de la langue sont des cas particuliers. Dans
-l'installateur Debian, si le milieu a été préparé pour un environnement de
-bureau particulier, la tâche correspondante sera automatiquement
-installée. Ainsi, il y a tâches #{gnome-desktop}#, #{kde-desktop}#,
-#{lxde-desktop}# et #{xfce-desktop}#, dont aucun n'est offert dans le menu
-#{tasksel}#. De même, il n'y a pas entrées de menu pour les tâches de les
-langues, mais le choix de la langue de l'utilisateur lors de l'installation
-influence le choix des tâches de la langue correspondante.
-
-En live-build, par conséquent, ces cas particuliers sont également d'une
-attention particulière, mais avec trois différences notables au moment de
-l'écriture.
-
-D'abord, il n'existe aucune disposition fait encore automatiquement pour des
-tâches de la langue, même si un sous-ensemble de ces packages sont inclus si
-vous spécifiez #{lb config --language}#. Si vous avez besoin de ces tâches,
-qui comprennent des éléments tels que des polices spécifiques de la lange et
-des paquets de méthodes d'entrée, vous devez les spécifier dans votre
-configuration. Par exemple:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-En second lieu, live-build supporte #{*-desktop}# listes de paquets virtuels
-pour chacune des saveurs de bureau mentionnés ci-dessus, qui sélectionnent
-la liste prédéfinie de paquets #{standard-x11}#, le correspondant
-#{*-desktop}# et trois tâches supplémentaires: #{desktop}#, #{standard}# et
-#{laptop}#. Ainsi, par exemple, si vous spécifiez #{--packages-lists
-gnome-desktop}#, il est équivalent à spécifier #{--packages
-debian-installer-launcher --packages-lists standard-x11 --tasks
-"gnome-desktop desktop standard laptop"}#.
-
-En troisième lieu, si une des tâches de bureau pour ces saveurs sont
-sélectionnés, soit explicitement par #{--tasks}# ou implicitement par
-#{--packages-lists}#, live-build préconfigurera la valeur de bureau
-correspondante pour l'installateur Debian (si elle est incluse) pour
-s'assurer qu'il suit ses propres règles pour l'installation de saveurs de
-bureau différents.
-
-*{Remarque:}* Il existe également une option expérimental #{--language}# qui a un objectif qui se chevauche avec des tâches des langues. Pour toute langue pour laquelle il est connu qu'il y a des paquets #{*-l10n}#, si #{--language}# est spécifié, ces paquets seront installés. Par ailleurs, si tous les modèles #{syslinux}# correspondants à la langue sont trouvés, ils seront utilisés au lieu des modèles par défaut en anglais. La sélection des paquets fait par #{--language}# est une mauvaise approximation aux tâches de langue, car elle exige que la liste des paquets à inclure par langue sera maintenu en interne en live-build, et d'ailleurs, des langues sont plus complets et flexibles. Cependant, l'aspect #{syslinux}# est encore utile. Ainsi, si vous utilisez #{--bootloader syslinux}# et des modèles pour la langue spécifiée existe, soit dans #{/usr/share/live/build/templates/syslinux/}# ou #{config/templates/syslinux/}#, pensez à utiliser cette option, évent
uellement en combinaison avec des tâches pour s'assurer que tous les paquets concernés sont installés. Par exemple:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Même ainsi, elle est limitée en ce qu'elle ne supporte que d'une seule
-langue et un chargeur de démarrage unique. Par conséquent, pour toutes ces
-raisons, l'avenir de cette option est à l'étude, qui pourrait être remplacé
-par quelque chose d'entièrement différent dans la prochaine version majeure
-de live-build.
-
-2~installing-modified-or-third-party-packages Installation des paquets
-modifiés ou de tiers
-
-Tandis qu'il est contre la philosophie de Debian Live, il peut parfois être
-nécessaire de construire un système live avec des versions modifiées des
-paquets qui sont dans le référentiel Debian. C'est peut-être de modifier ou
-soutenir des fonctionnalités supplémentaires, des langues et de la marque,
-ou même de supprimer des éléments de paquets existants qui sont
-indésirables. De même, les paquets "de tiers" peuvent être utilisés pour
-ajouter des fonctionnalités sur mesure et/ou propriétaires.
-
-Cette section ne couvre pas les conseils concernant la construction ou la
-maintenance des paquets modifiés. La méthode de Joachim Breitner 'How to
-fork privately'
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
-peut, cependant, être d'intérêt. La création de paquets sur mesure sont
-couverts dans le Debian New Maintainers' Guide at
-http://www.debian.org/doc/maint-guide/ et ailleurs
-
-Il y a deux façons d'installer des paquets personnalisés modifiés:
-
-_* #{chroot_local-packages}#
-
-_* En utilisant un référentiel APT personnalisé
-
-Utilisant #{chroot_local-packages}# est plus simple à réaliser et utile pour
-les personnalisations ponctuels mais a un certain nombre d'inconvénients,
-tout en utilisant un réferéntiel personnalisé APT est plus fastidieux à
-mettre en place.
-
-3~ Utilisant #{chroot_local-packages}# pour installer paquets personnalisés
-
-Pour installer un paquet personnalisé, il suffit de le copier dans le
-répertoire #{config/chroot_local-packages/}#. Les paquets qui sont dans ce
-répertoire seront automatiquement installés dans le système live pendant la
-construction du systéme - vous n'avez pas besoin de les spécifier ailleurs.
-
-Les paquets *{doivent}* être nommés de la manière prescrite. Une façon
-simple de le faire consiste à utiliser #{dpkg-name}#.
-
-L'utilisation de #{chroot_local-packages}# pour l'installation de paquets
-personnalisés a des inconvénients:
-
-_* Il n'est pas possible d'utiliser secure APT.
-
-_* Vous devez installer tous les paquets appropriés dans le répertoire
-#{config/chroot_local-packages/}#.
-
-_* Il ne se prête pas au stockage de configurations Debian Live dans le
-contrôle de révision.
-
-3~ Utilisant un référentiel APT pour installer des paquets personnalisés.
-
-Contrairement à l'utilisation de #{chroot_local-packages}#, lorsque vous
-utilisez un réferéntiel personnalisé APT vous devez vous assurer que vous
-spécifiez les paquets ailleurs. Voir {Choisir les paquets à
-installer}#choosing-packages-to-install pour plus de détails.
-
-Si créer un référentiel APT pour installer des packages personnalisés peut
-sembler un effort inutile, l'infrastructure peut être facilement ré-utilisée
-à une date ultérieure pour offrir les mises à jour des paquets modifiés.
-
-3~ Les paquets personnalisés et APT
-
-live-build utilise apt pour installer tous les paquets dans le système live
-donc il héritera des comportements de ce logiciel. Un exemple pertinent est
-que (en supposant une configuration par défaut), étant donné un paquet
-disponible dans deux référentiels différents avec différents numéros de
-version, APT choisira d'installer le paquet avec la numéro de version
-supérieur.
-
-Pour cette raison, vous pouvez incrémenter le numéro de version dans les
-fichiers #{debian/changelog}# de vos paquets personnalisés pour s'assurer
-que votre version modifiée est installée en lieu d'une dans les référentiels
-officiels Debian. Cela peut aussi être atteint en modifiant les préférences
-de pinning d'APT dans le système live - voir {APT pinning}#apt-pinning pour
-plus d'informations.
-
-2~ Configuration d'APT au moment de la construction
-
-Vous pouvez configurer APT par un certain nombre d'options appliquées
-uniquement au moment de la construction. (La configuration d'APT utilisé
-dans le système live en fonctionnement peut être configurée de façon normale
-pour un système live, qui est, en incluant les configurations appropriées à
-#{config/chroot_local_includes/}#.) Pour une liste complète, regardez les
-options commençant par #{apt}# dans la page de manuel de #{lb_config}#.
-
-3~choosing-apt-or-aptitude Choisir apt ou aptitude
-
-Vous pouvez choisir d'utiliser soit #{apt}# ou #{aptitude}# Quel logiciel
-est utilisé est régi par l'argument #{--apt}# de #{lb config}#. Choisissez
-la méthode du comportement préférée pour l'installation de paquets, la
-différence notable étant la manière dont les paquets manquants sont
-traitées.
-
-_* #{apt}#: Avec cette méthode, si un paquet manquant est spécifié,
-l'installation va échouer. C'est le paramètre par défaut.
-
-_* #{aptitude}#: Avec cette méthode, si un paquet manquant est spécifié,
-l'installation va réussir.
-
-3~ Utilisation d'un proxy avec APT
-
-Une configuration communément requis par APT est pour faire face à la
-construction d'une image derrière un proxy. Vous pouvez spécifier votre
-proxy APT avec les options #{--apt-ftp-proxy}# ou #{--apt-http-proxy}# si
-nécessaire, par exemple
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Régler APT pour économiser de l'espace
-
-Vous pouvez avoir besoin d'économiser de l'espace sur les supports d'images,
-auquel cas l'un ou l'autre ou les deux options suivantes peuvent être
-d'intérêt.
-
-Si vous ne voulez pas inclure les indices de l'APT dans l'image, vous les
-pouvez omettre avec:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-Cela ne influencera les entrées dans /etc/apt/sources.list, mais simplement
-de savoir si /var/lib/apt contient les fichiers indices ou non. La
-contrepartie est que APT a besoin de ces indices afin d'opérer dans le
-système live, alors avant de procéder à #{apt-cache search}# or #{apt-get
-install}#, par exemple, l'utilisateur doit faire #{apt-get update}# pour
-créer ces indices.
-
-Si vous trouvez que l'installation des paquets recommandés gonfle votre
-image trop, vous pouvez désactiver l'option par défaut d'APT avec:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-La contrepartie ici est que si vous n'installez pas les paquets recommandés
-par un paquet, c’est-à-dire, "paquets qu'on trouverai avec celui-ci dans
-toute installation standard" (Debian Policy Manual, section 7.2), certains
-paquets que vous avez vraiment besoin peuvent être omis. Par conséquent,
-nous vous suggérons d'examiner la différence de désactiver recommends rend à
-votre liste de paquets (voir le fichier #{binary.packages}# généré par #{lb
-build}#) et re-inclure dans votre liste tous les paquets manquants que vous
-souhaitez toujours installées. Alternativement, si vous trouvez que vous
-voulez seulement un petit nombre de paquets recommandés exclus, laissez
-recommends activé et défini une priorité APT pin négative sur les paquets
-sélectionnés pour éviter les installér, comme expliqué dans {APT
-pinning}#apt-pinning.
-
-3~ Passer des options à apt ou aptitude
-
-S'il n'y a pas une option #{lb config}# pour modifier le comportement d'APT
-dans la façon dont vous avez besoin, utiliser #{--apt-options}# ou
-#{--aptitude-options}# pour passer des options grâce à votre outil APT
-configuré. Voir les pages de manuel #{apt}# et #{aptitude}# pour plus de
-détails
-
-3~apt-pinning APT pinning
-
-Pour le contexte, s'il vous plaît lire d'abord la page de manuel
-#{apt_preferences(5)}#. APT pinning peut être configuré soit pour le temps
-de construction, ou encore pendant l'exécution. Pour le premier, créez
-#{config/chroot_apt/preferences}#. Pour ce dernier, créez
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Imaginons que vous voulez construire un système live Squeeze mais il faut
-installer tous les paquets live qui finissent dans l'image binaire depuis
-Sid au moment de la construction. Vous devez ajouter Sid à votre APT sources
-et le fixer de sorte que seulement les paquets que vous voulez sont
-installés au temps de construction et tous les autres sont de la
-distribution du système cible, Squeeze. Ce qui suit devrait accomplir ça:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Remarque:}* Caractères génériques peuvent être utilisés dans les noms des paquets (par exemple *{Package: live-*}*) avec la version 0.8.14 ou supérieure d'Apt. Cela signifie qu'il fonctionne avec Wheezy en utilisant:
-
-code{
-
-$ lb config --distribution wheezy
-
-}code
-
-Une priorité pin négative évitera installér un paquet, comme dans le cas où
-vous ne voulez pas un paquet qui est recommandé par un autre
-paquet. Supposons que vous construisez une image LXDE en utilisant l'option
-#{--packages-lists lxde}# mais ne veulez pas que l'utilisateur soit invité à
-stocker les mots de passe wifi dans le trousseau de clés. Cette liste
-comprend #{gdm}#, que dépend de #{gksu}#, que à son tour recommends
-#{gnome-keyring}#. Donc, vous voulez omettre le paquet recommandé
-#{gnome-keyring}#. Cela peut être fait en ajoutant la strophe suivante à
-#{config/chroot_apt/preferences}#:
-
-code{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/fr/user_customization-runtime.ssi b/manual/fr/user_customization-runtime.ssi
deleted file mode 100644
index f2f919e..0000000
--- a/manual/fr/user_customization-runtime.ssi
+++ /dev/null
@@ -1,253 +0,0 @@
-:B~ Personnalisation des comportements au moment de l'exécution
-
-1~customizing-run-time-behaviours Personnalisation des comportements au
-moment de l'exécution
-
-Toute la configuration qui est fait pendant l'exécution est fait par
-live-config. Voici quelques options les plus courantes de live-config
-d'intérêt pour les utilisateurs. Une liste complète de toutes les
-possibilités peut être trouvée dans la page de manuel de live-config.
-
-2~ Personnalisation de l'utilisateur Live
-
-Une considération importante est que l'utilisateur live est créé par
-live-boot au démarrage, non pas par live-config au moment de la
-construction. Ça influence non seulement là où les documents relatifs à
-l'utilisateur live sont introduits dans votre construction, tel que discuté
-dans {Live/chroot local includes}#live-chroot-local-includes, mais aussi
-tous les groupes et les autorisations associées à l'utilisateur live.
-
-Vous pouvez spécifier d'autres groupes pour l'utilisateur live en
-préconfigurant la valeur debconf #{passwd/user-default-groups}#. Par
-exemple, pour ajouter l'utilisateur live au groupe #{fuse}# ajoutez la ligne
-suivante à un fichier dans le répertoire #{config/chroot_local-preseed}#:
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-Il est également possible de changer le nom d'utilisateur par défaut «user»
-et du mot de passe par défaut "live". Si vous voulez pour quelque raison,
-vous pouvez facilement faire ça comme suit:
-
-Pour modifier le nom d'utilisateur par défaut, vous pouvez simplement le
-spécifier dans votre config:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-Une façon possible de changer le mot de passe par défaut est au moyen d'un
-hook comme décrit dans {Hooks au moment du démarrage}#boot-time-hooks. Pour
-ce faire vous pouvez utiliser le hook "passwd" de
-#{/usr/share/doc/live-config/examples/hooks}#, ajouter un préfixe correct
-(par exemple 200-passwd) et l'ajouter à
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Personnalisation des paramètres régionaux
-et la langue
-
-Au démarrage du système live, la langue est impliqué dans trois étapes:
-
-_* la génération des paramètres régionaux
-
-_* réglage de la disposition du clavier pour la console
-
-_* réglage de la disposition du clavier pour X
-
-Les paramètres régionaux par défaut pendant la construction d'un système
-Live sont "locales=en_US.UTF-8". Pour définir les paramètres régionaux qui
-doivent être générés, utilisez le paramètre #{locales}# dans l'option
-#{--bootappend-live}# de #{lb config}#, par exemple
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-Ce paramètre peut également être utilisé à la ligne de commande du
-noyau. Vous pouvez spécifier des paramètres régionaux par
-#{language_country.encoding}#.
-
-Tant la console et la configuration du clavier X dépendent du paramètre
-#{keyboard-layouts}# de l'option #{--bootappend-live}#. Options valides pour
-les dispositions des claviers X peuvent être trouvés dans
-#{/usr/share/X11/xkb/rules/base.xml}# (plutôt limitées à des codes des pays
-à deux lettres). Pour trouver la valeur (les deux caractères), correspondant
-à une langue essayez de rechercher le nom anglais de la nation où la langue
-est parlée, par exemple:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-Pour obtenir les fichiers des paramètres régionaux pour les claviers
-allemand et suisse allemand dans X utiliser:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-Une liste des valeurs valides des claviers pour la console peut être figuré
-avec la commande suivante:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-Alternativement, vous pouvez utiliser le paquet #{console-setup}#, un outil
-pour vous permettre de configurer la disposition de la console en utilisant
-définitions X (XKB), vous pouvez alors définir votre clavier plus
-précisément avec variables #{keyboard-layouts}#, #{keyboard-variant}#,
-#{keyboard-options}# et #{keyboard-model}#; live-boot pourra également
-utiliser ces paramètres pour la configuration de X. Par exemple, pour mettre
-en place un système français avec une disposition Français Dvorak (appelée
-Bepo) sur un clavier TypeMatrix, à la fois dans la console et X11, utilisez:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistance
-
-Un paradigme d'un Live CD est être un système pré-installé qui se démarre du
-support en lecture seule, comme un cdrom, où les données et les
-modifications ne survivent pas aux redémarrages du matériel hôte qui
-l'exécute.
-
-Un système Debian Live est une généralisation de ce paradigme et soutient
-ainsi autres supports, en plus de CDs, mais encore, dans son comportement
-par défaut, il doit être considéré en lecture seule et toutes les évolutions
-d'exécution du système sont perdus à l'arrêt.
-
-La persistance est un nom commun pour les différents types de solutions pour
-sauver, après un redémarrage, certaines ou toutes les données, de cette
-évolution pendant l'exécution du système. Pour comprendre comment cela
-pourrait fonctionner il pourrait être utile de savoir que même si le système
-est démarré et exécuté à partir d'un support en lecture seule, la
-modification des fichiers et répertoires sont écrits sur des supports
-inscriptibles, typiquement un disque ram (tmpfs) et aux disques RAM les
-données ne survivent pas à un redémarrage.
-
-Les données stockées sur ce disque virtuel doivent être enregistrées sur un
-support inscriptible persistant comme un disque dur, une clé USB, un partage
-réseau ou même une séance d'un CD/DVD multisession (ré)inscriptible. Tous
-ces supports sont pris en charge dans Debian Live de différentes manières,
-et tous mais le dernier nécessitent un paramètre de démarrage spéciale à
-préciser au moment du démarrage: #{persistent}#.
-
-3~ Persistance pleine
-
-Par «persistance pleine» on entend que plutôt que d'utiliser un tmpfs pour
-le stockage des modifications au support en lecture seule (avec le système
-copy-on-write, COW) une partition accessible en écriture est utilisée. Pour
-utiliser cette fonction une partition avec un système de fichiers accessible
-en écriture avec l'étiquette "live-rw" doit être fixé sur le système au
-moment du démarrage et le système doit être démarré avec le paramètre de
-démarrage "persistent". Cette partition peut être une partition ext2 du
-disque dur ou sur une clé USB créé avec, par exemple:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-Voir aussi {Utilisation de l'espace disponible sur une clé
-USB}#using-usb-extra-space.
-
-Si vous avez déjà une partition sur votre dispositif, vous pouvez simplement
-modifier l'étiquette avec l'un des suivants:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-Mais puisque les utilisateurs du système live ne peuvent pas toujours
-utiliser une partition du disque dur, et considérant que la plupart des clés
-USB ont des vitesses d'écriture pauvres, «pleine» persistance pourrait
-également être utilisé avec des fichiers image, si vous pouviez créer un
-fichier qui représente une partition et mettre cette image fichier, même sur
-une partition NTFS d'un système d'exploitation étranger, avec quelque chose
-comme:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-Ensuite, copiez le fichier #{live-rw}# sur une partition accessible en
-écriture et redémarrer avec le paramètre de démarrage "persistent".
-
-3~ Montage automatique de Home
-
-Si lors de l'initialisation une partition (système de fichiers) un fichier
-image ou une partition étiquetée #{home-rw}# est découverte, ce système de
-fichiers sera monté directement comme #{/home}#, permettant ainsi la
-persistance des fichiers qui appartiennent à l'utilisateur par défaut. Elle
-peut être combinée avec la persistance complète.
-
-3~ Instantanés
-
-Les instantanés sont des collections de fichiers et de répertoires qui ne
-sont pas montés lors de l'exécution, mais qui sont copiés à partir d'un
-périphérique persistant à le système (tmpfs) au démarrage et qui sont
-resynchronisés au redémarrage/arrêt du système. Le contenu d'un instantané
-pourrait résider sur une partition ou un fichier image (comme les types
-mentionnés ci-dessus) étiquetés #{live-sn}#, mais il est par défaut à une
-archive cpio simple appelé #{live-sn.cpio.gz}#. Comme ci-dessus, au moment
-du démarrage, les périphériques connectés à le système sont examinés pour
-voir si une partition ou un fichier nommé comme ça pourrait être trouvé. Une
-coupure de courant pendant l'exécution pourrait conduire à la perte de
-données, donc un outil appelé #{live-snapshot --refresh}# pourrait être
-appelé à synchroniser des changements importants. Ce type de persistance,
-car elle n'écrit pas continuellement dans les supports persistants, est le
-plus respectueux avec les dispositifs flash et le plus rapide de tous les
-systèmes de persistance.
-
-Une version instantané de /home existe aussi, et son étiquette est
-#{home-sn.*}#; elle travaille le même que l'instantané principale, mais il
-est seulement appliquée à /home.
-
-Les instantanés ne peuvent pas actuellement gérer la suppression de
-fichiers, mais la persistance pleine et le montage automatique de home si
-peuvent le faire.
-
-3~ SubText persistant
-
-Si un utilisateur a besoin de multiples stockages persistants du même type
-pour différents endroits ou l'essai, tel que #{live-rw-nonwork}# et
-#{live-rw-work}#, le paramètre de démarrage #{persistent-subtext}# utilisé
-en conjonction avec le paramètre de démarrage #{persistent}# permettra
-multiples mais uniques supports persistants. Un exemple serait le cas si un
-utilisateur voudrait utiliser une partition persistante étiqueté
-#{live-sn-subText}# il utiliserait les paramètres de démarrage:
-#{persistent}# #{persistent-subtext=subText}#.
-
-3~ Remasterisation partielle
-
-Les modifications de l'exécution du tmpfs pourraient être recueillies à
-l'aide de live-snapshot dans une squashfs et ajoutés au CD en remasterisant
-l'ISO dans le cas des CD-R ou en ajoutant une session à un cd/dvd(rw)
-multisession; live-boot monte tous les systèmes de fichiers /live dans
-l'ordre ou avec le paramètre de démarrage du module.
diff --git a/manual/fr/user_examples.ssi b/manual/fr/user_examples.ssi
deleted file mode 100644
index 86bfafa..0000000
--- a/manual/fr/user_examples.ssi
+++ /dev/null
@@ -1,420 +0,0 @@
-:B~ Exemples
-
-1~examples Exemples
-
-Ce chapitre s'occupe d'exemples de constructions pour les cas d'utilisation
-spécifiques avec Debian Live. Si vous êtes nouveau avec la construction de
-vos propres images Debian Live, nous vous recommandons d'abord regarder les
-trois tutoriels en séquence, comme chacun apprend nouvelles techniques qui
-vous aideront à utiliser et à comprendre les exemples restants.
-
-2~using-the-examples En utilisant les exemples
-
-Pour utiliser ces exemples vous avez besoin d'un système pour les
-construire, lequel répond aux exigences énumérées dans
-{Exigences}#requirements et vous avez live-build installe comme décrit à
-{Installation de live-build}#installing-live-build.
-
-Notez que, pour des raisons de concision, dans ces exemples, nous ne
-spécifions pas un miroir local à utiliser pour la construction. Vous pouvez
-accélérer considérablement les téléchargements si vous utilisez un miroir
-local. Vous pouvez spécifier les options lorsque vous utilisez #{lb
-config}#, tel que décrit dans {Miroirs de distribution utilisés au temps de
-construction}#distribution-mirrors-build-time, ou pour plus de commodité,
-fixez par défaut votre système de construction dans
-#{/etc/live/build.conf}#. Il suffit de créer ce fichier et de définir les
-variables #{LB_MIRROR_*}# correspondantes à votre miroir préféré. Par
-exemple:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: Une image standard
-
-*{Cas d'utilisation:}* Créer une image simple d'abord, apprenant les bases de live-build.
-
-Dans ce tutoriel, nous construirons une image Debian Live ISO hybride par
-défaut contenant uniquement paquets de base (pas de Xorg) et quelques
-paquets Debian de soutien live, comme un premier exercice en utilisant
-live-build.
-
-Vous ne pouvez pas obtenir beaucoup plus simple que cela:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Examinez le contenu du répertoire #{config/}# si vous le souhaitez. Vous
-verrez stockés ici une configuration du squelette, pour être personnalise
-ou, dans ce cas, utiliser immédiatement pour construire une image par
-défaut.
-
-Maintenant, en tant que superutilisateur, construire l'image en enregistrant
-un journal avec #{tee}#.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-En supposant que tout se passe bien, après un certain temps, le répertoire
-courant contient #{binary-hybrid.iso}#. Cette image ISO hybride peut être
-démarré directement dans une machine virtuelle comme décrit dans {Test d'une
-image ISO avec QEMU}#testing-iso-with-qemu et {Test d'une image ISO avec
-virtualbox-ose}#testing-iso-with-virtualbox, ou bien copiés sur un support
-optique ou un périphérique USB comme décrit dans {Graver une image ISO sur
-un support physique}#burning-iso-image et {Copie d'un image ISO hybride sur
-une clé USB}#copying-iso-hybrid-to-usb, respectivement.
-
-2~tutorial-2 Tutoriel 2: Un utilitaire de navigateur Web
-
-*{Cas d'utilisation:}* Créer une image d'un utilitaire de navigateur Web, en apprenant à appliquer des personnalisations.
-
-Dans ce tutoriel, nous allons créer une image utilisable comme un utilitaire
-de navigateur Web, en servant d'introduction à la personnalisation d'images
-Debian Live.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-Notre choix de LXDE pour cet exemple reflète notre volonté de fournir un
-environnement de bureau minime, puisque le point de l'image est
-l'utilisation unique, nous avons à l'esprit, le navigateur web. On pourrait
-aller encore plus loin et offrir une configuration par défaut pour le
-navigateur web dans #{config/chroot_local-includes/etc/iceweasel/profile/}#,
-ou des paquets de soutien supplémentaires pour visualiser différents types
-de contenu web, mais nous laissons cela comme une exercice pour le lecteur.
-
-Construire l'image, encore une fois en tant que superutilisateur, tenir un
-journal comme dans {Tutoriel 1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Encore une fois, vérifiez que l'image est OK et faire un test, comme dans
-{Tutoriel 1}#tutorial-1:
-
-2~tutorial-3 Tutoriel 3: Une image personnalisée
-
-*{Cas d'utilisation:}* Créer un projet pour construire une image personnalisée, contenant vos logiciels préférés à emporter avec vous sur une clé USB où que vous alliez, et évoluant dans des révisions successives selon vos besoins et vos préférences changent.
-
-Puisque nous allons changer notre image personnalisée pendant un certain
-nombre de révisions, et nous voulons suivre ces changements, d'essayer des
-choses expérimentalement et éventuellement de les revenir si les choses ne
-fonctionnent pas, nous garderons notre configuration dans le populaire
-système de contrôle de version #{git}#. Nous allons également utiliser les
-meilleures pratiques d'autoconfiguration via #{auto}# scripts tel que décrit
-dans {Gestion d'une configuration}#managing-a-configuration.
-
-3~ Première révision
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Éditer #{auto/config}# pour lire comme suit:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-Tout d'abord, #{--architecture i386}# assure que sur notre système de
-construction #{amd64}#, nous construisons une version 32 bits qui peut être
-utilisé sur la plupart des machines. Deuxièmement, nous utilisons
-#{--linux-flavours 686}# parce que nous ne prévoyons pas utiliser cette
-image sur des systèmes beaucoup plus anciens. Troisièmement, nous avons
-choisi la liste des paquets #{lxde}# pour nous donner un bureau minimal. Et
-enfin, nous avons ajouté deux premiers paquets préférés: #{iceweasel}# et
-#{xchat}#.
-
-Maintenant, construire l'image:
-
-code{
-
- # lb build
-
-}code
-
-Notez que contrairement aux deux premiers tutoriels, nous n'avons plus
-besoin de taper #{2>&1 | tee binary.log}# parce que cela est maintenant
-inclus dans #{auto/build}#.
-
-Une fois que vous avez testé l'image (comme dans {Tutoriel 1}#tutorial-1) et
-êtes satisfait avec son fonctionnement, il est temps pour initialiser notre
-référentiel #{git}#, ajoutant que les scripts d'auto que nous avons juste
-créé, et ensuite faire le premier commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Deuxième révision
-
-Dans cette révision, nous allons nettoyer à partir de la première
-construction, ajouter le paquet #{vlc}# à notre configuration, reconstruire,
-tester et faire le commit.
-
-La commande #{lb clean}# va nettoyer tous les fichiers générés par la
-construction précédente à l'exception du cache, ça évite d'avoir à
-re-télécharger les paquets. Cela garantit que le #{lb build}# postérieure
-ré-exécutera toutes les étapes pour régénérer les fichiers de notre nouvelle
-configuration.
-
-code{
-
- # lb clean
-
-}code
-
-Maintenant, éditez #{auto/config}# pour ajouter le paquet #{vlc}#:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Construire à nouveau:
-
-code{
-
-# lb build
-
-}code
-
-Tester, et quand vous êtes satisfaits, commit la prochaine révision:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Bien sûr, des changements plus compliqués à la configuration sont possibles,
-peut-être l'ajout de fichiers dans les sous-répertoires de
-#{config/}#. Quand vous livrez des nouvelles révisions, il suffit de prendre
-soin de ne pas modifier à la main ou commit les fichiers de niveau supérieur
-dans #{config}# contenant variables #{LB_*}#, car ce sont des produits de
-creation, aussi, et sont toujours nettoyés par #{lb clean}# et re-créés avec
-#{lb config}# via leur respectives #{auto}# scripts.
-
-Nous sommes arrivés à la fin de notre série de tutoriels. Alors que de
-nombreux types de personnalisations sont possibles, même juste en utilisant
-les fonctionnalités explorées dans ces exemples simples, une variété presque
-infinie d'images différentes peuvent être crées. Les autres exemples de
-cette section couvrent plusieurs autres cas d'utilisation tirés des
-expériences recueillies des utilisateurs de Debian Live.
-
-2~ Un client Kiosk VNC
-
-*{Cas d'utilisation:}* Créer une image avec live-build pour démarrer directement à un serveur VNC.
-
-Faire un répertoire de construction et créer une configuration du squelette
-construit autour de la liste standard x11, avec #{gdm3}#, #{metacity}# et
-#{xtightvncviewer}#, désactivant «recommends» pour faire un système minimal:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Créez le répertoire #{/etc/skel}# avec une #{.xsession}# personnalisée pour
-l'utilisateur par défaut qui va lancer metacity et commencer xvncviewer, en
-reliant le port #{5901}# sur un serveur à #{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Construire l'image:
-
-code{
-
- # lb build
-
-}code
-
-Amusez-vous bien!
-
-2~ Une image de base pour une clé USB de 128M
-
-*{Cas d'utilisation:}* Créer une image standard avec certains composants éliminés afin de s'adapter sur une clé USB avec 128M avec espace laissé pour l'utiliser à votre convenance.
-
-Lorsque l'optimisation d'une image adaptée à une dimension des certains
-supports, vous avez besoin de comprendre le compromis que vous faites entre
-la taille et la fonctionnalité. Dans cet exemple, nous réduisons uniquement
-que pour faire place à du matériel supplémentaire au sein d'une taille de
-128M, mais sans rien faire pour détruire l'intégrité des paquets contenus,
-telles que la purge des données de localisation via le paquet
-#{localepurge}#, ou d'autres tels optimisations "intrusives". On notera en
-particulier, vous ne devriez pas utiliser #{--bootstrap-flavour minimal}#
-sauf si vous savez vraiment ce que vous faites, que l'omission de paquets de
-priorité #{importants}# produira probablement un système live cassé.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Maintenant, construire l'image de la manière habituelle:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Sur le système de l'auteur au moment de l'écriture, la configuration
-ci-dessus produit une image de 78Mbyte. Cela se compare favorablement avec
-l'image de 166Mbyte produite par la configuration par défaut dans {Tutoriel
-1}#tutorial-1.
-
-Le plus grand espace-économiseur ici, par rapport à la construction d'une
-image standard sur une architecture #{i386}#, est de sélectionner uniquement
-le saveur du noyau #{486}# au lieu de la valeur par défaut #{-k "486
-686"}#. Laissant hors indices APT avec #{--binary-indices false}# permet
-aussi d'économiser une bonne quantité d'espace, le compromis étant que vous
-devez faire #{apt-get update}# avant d'utiliser apt dans le système
-live. Le choix de la liste #{minimal}# laisse de côté les grands paquets de
-#{locales}# et les services associés. Laissant hors les paquets recommandés
-économise de l'espace supplémentaire, au détriment d'omettre certains
-paquets vous pourriez autrement s'attendre à être là, tel que
-#{firmware-linux-free}# qui peuvent être nécessaires pour prise en charge
-matérielle de certains supports matériels. Les options restantes économisent
-petites quantités d'espace supplémentaires. C'est à vous de décider si la
-fonctionnalité qui est sacrifié avec chaque optimisation est en vaut la
-perte de fonctionnalité.
-
-2~ Un bureau KDE localisé et installateur
-
-*{Cas d'utilisation:}* Créer une image de bureau KDE, localisé pour le portugais brésilien et incluant un installateur.
-
-Nous voulons faire une image iso-hybride pour l'architecture i386 en
-utilisant notre bureau préféré, dans ce cas, KDE, contenant tous les paquets
-mêmes qui seraient installés par l'installateur Debian standard pour KDE.
-
-Notre premier problème est la découverte des noms des tâches
-appropriées. Actuellement, live-build ne peut pas aider. Alors que nous
-pourrions être chanceux et trouver ce par essais et erreurs, il y a un
-outil, #{grep-dctrl}#, qui peut être utilisé pour découvrir des descriptions
-de tâche dans tasksel-data, de sorte à préparer, assurez-vous que vous avez
-ces deux choses:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Maintenant, nous pouvons rechercher les tâches appropriées, d'abord avec:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-Par cette commande, nous découvrons la tâche est appelée, assez clairement,
-brazilian-portuguese. Maintenant, pour trouver les tâches liées:
-
-code{
-
- $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-Nous allons utiliser l'option expérimentale #{--language}#, comme live-build
-inclut #{syslinux}# pour pt_BR (voir {Tâches de bureau et de la
-langue}#desktop-and-language-tasks pour plus de détails). Et au moment du
-démarrage nous allons générer les paramètres régionaux pt_BR.UTF-8 et
-sélectionner la configuration du clavier pt-latin1. Maintenant, nous allons
-mettre les pièces ensemble:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Notez que nous avons inclus le paquet #{debian-installer-launcher}# pour
-lancer l'installateur depuis le bureau live, et ont également précisé que le
-noyau 486, tel qu'il est actuellement nécessaire pour faire que
-l'installateur et le noyau du systéme live matchent pour que le lanceur
-fonctionne correctement.
diff --git a/manual/fr/user_installation.ssi b/manual/fr/user_installation.ssi
deleted file mode 100644
index 157648f..0000000
--- a/manual/fr/user_installation.ssi
+++ /dev/null
@@ -1,182 +0,0 @@
-:B~ Installation
-
-1~installation Installation
-
-2~requirements Exigences
-
-Les exigences pour la création des images Debian Live sont très peu:
-
-_* Super-utilisateur (root) accès
-
-_* Une version mise à jour de live-build
-
-_* Un shell POSIX, tel que /{bash}/ ou /{dash}/.
-
-_* /{debootstrap}/ ou /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Notez que l'utilisation de Debian ou une distribution dérivée de Debian
-n'est pas nécessaire - live-build fonctionne sur presque toute distribution
-avec les exigences ci-dessus.
-
-2~installing-live-build Installation de live-build
-
-Vous pouvez installer live-build en un certain nombre de façons différentes:
-
-_* Depuis le référentiel Debian
-
-_* Depuis le code source
-
-_* À partir des instantanés
-
-Si vous utilisez Debian, la méthode recommandée consiste à installer
-live-build depuis le référentiel Debian.
-
-3~ Depuis le référentiel Debian
-
-Il suffit d'installer live-build comme n'importe quel autre paquet:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-ou
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ Depuis le code source
-
-live-build est développé en utilisant le système de contrôle de version
-Git. Dans les systèmes basés sur Debian, cela est fourni par le paquet
-/{git}/ Pour examiner le dernier code, exécutez:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-Vous pouvez compiler et installer votre propre paquet Debian en exécutant:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Maintenant, installez celui des fichiers récemment construits que vous
-intéresse, p. ex
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-Vous pouvez également installer live-build directement sur votre système en
-exécutant:
-
-code{
-
- # make install
-
-}code
-
-et le désinstaller avec:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ À partir des instantanés
-
-Si vous ne souhaitez pas de créer ou d'installer live-build depuis les
-sources, vous pouvez utiliser des instantanés. Ils sont construits
-automatiquement à partir de la dernière version du Git et ils sont
-disponibles à http://live.debian.net/debian/.
-
-2~ live-boot et live-config
-
-*{Remarque:}* Vous n'avez pas besoin d'installer live-boot ou live-config sur votre système afin de créer des systèmes Debian Live. Cependant, cela ne fera aucun mal et est utile à des fins de référence. Si vous voulez seulement la documentation, vous pouvez maintenant installer les paquets live-boot-doc et live-config-doc séparément.
-
-3~ Depuis le référentiel Debian
-
-Tous deux live-boot et live-config sont disponibles dans le référentiel
-Debian comme {Installation de live-build}#installing-live-build.
-
-3~ Depuis le code source
-
-Pour utiliser les dernières sources du git, vous pouvez suivre le procédure
-ci-dessous. S'il vous plaît assurer que vous êtes familiarisé avec les
-termes mentionnés dans {Termes}#terms.
-
-_* Examiner les sources de live-boot et live-config
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Consultez les pages de manuel de live-boot et live-config pour plus de
-détails sur la personnalisation si c'est votre raison pour la création de
-vos paquets depuis les sources.
-
-_* Créer les fichiers .deb de live-boot et live-config
-
-Vous devez créer sur votre distribution objectif ou en chroot contenant
-votre plateforme objectif: cela signifie que si votre objectif est Squeeze
-alors vous devez créer sur Squeeze.
-
-Utilisez un système de construction automatique personnel tels que
-/{pbuilder}/ ou /{sbuild}/ si vous avez besoin pour créer #{live-boot}# pour
-une distribution objectif qui diffère de votre système de construction. Par
-exemple, pour les images live de Squeeze, créez #{live-boot}# dans un chroot
-Squeeze. Si votre distribution objectif correspond à votre distribution vous
-pouvez créer directement sur le système de construction en utilisant
-#{dpkg-buildpackage}# (fournis par le paquet /{dpkg-dev}/):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Utilisez tous les fichiers .deb générés.
-
-Comme live-boot et live-config sont installés par le système live-build,
-l'installation des paquets dans le système hôte ne suffit pas: vous devez
-traiter les fichiers .deb générés comme aucun autre paquet
-personnalisé. S'il vous plaît voir {Personnalisation de l'installation de
-paquets}#customizing-package-installation pour plus d'informations. Vous
-devriez prêter une attention particulière à {Référentiels
-supplémentaires}#additional-repositories.
-
-3~ À partir des instantanés
-
-Vous pouvez laisser live-build utiliser automatiquement les derniers
-instantanés de live-boot et live-config configurant un référentiel de tierce
-partie dans votre répertoire de configuration de live-build. En supposant
-que vous avez déjà créé un arbre de configuration dans le répertoire courant
-avec #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/fr/user_managing_a_configuration.ssi b/manual/fr/user_managing_a_configuration.ssi
deleted file mode 100644
index ed49dc0..0000000
--- a/manual/fr/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,98 +0,0 @@
-:B~ Gestion d'une configuration
-
-1~managing-a-configuration Gestion d'une configuration
-
-Ce chapitre explique comment gérer une configuration d'un système live à
-partir d'une création initiale, à travers des révisions successives et des
-versions successives du logiciel live-build et de l'image live lui-même.
-
-2~ Utilisez auto pour gérer les modifications de configuration
-
-Les configurations live sont rarement parfaites du premier coup. Vous aurez
-probablement besoin de faire une série de révisions jusqu'à ce que vous êtes
-satisfait. Cependant, des incohérences peuvent se glisser dans votre
-configuration d'une révision à la prochaine si vous ne faites pas
-attention. Le principal problème est, une fois qu'une variable est donné une
-valeur par défaut, cette valeur ne sera pas recalculé à partir d'autres
-variables qui peuvent changer dans les révisions ultérieures.
-
-Par exemple, lorsque la distribution est d'abord définie, nombreuses
-variables sont assignées des valeurs par défaut qui conviennent à cette
-distribution. Cependant, si vous décidez ultérieurement de modifier la
-distribution, ces variables dépendantes conservent les anciennes valeurs qui
-ne sont plus appropriés.
-
-Un deuxième problème connexe est que si vous exécutez #{lb config}# et
-ensuite mettez à jour une nouvelle version de live-build qui a changé l'un
-des noms de variables, vous découvrirez ce que par un examen manuel des
-variables dans votre #{config/*}# fichiers, que vous devrez ensuite utiliser
-pour définir l'option appropriée à nouveau.
-
-Tout cela serait une nuisance terrible si ce n'était pas pour les scripts
-auto/* simples emballages pour les commandes #{lb config}#, #{lb build}# et
-#{lb clean}# qui sont conçus pour vous aider gérer votre configuration. Il
-suffit de créer un script auto/config contenant la commande #{lb config}#
-avec toutes les options désirées, et un auto/clean qui supprime les fichiers
-contenant les valeurs des variables de configuration, et chaque fois que
-vous #{lb config}# et #{lb clean}#, ces fichiers seront exécutés. Cela
-permettra d'assurer que votre configuration a une cohérence interne d'une
-révision à l'autre et d'une version de live-build à la suivante (même si
-vous aurez encore de prendre soin et lire la documentation lorsque vous
-faites un mise à niveau et faites les ajustements nécessaires ).
-
-2~ Exemples de scripts auto
-
-Utiliser des exemples de scripts auto tels que les suivants comme point de
-départ pour votre nouveau configuration de live-build. Prenez note que
-lorsque vous appelez la commande #{lb}# que votre script auto emballage vous
-devez spécifier #{noauto}# comme paramètre afin de s'assurer que le script
-automatique n'est pas appelé à nouveau, de façon récursive. Aussi, n'oubliez
-pas de s'assurer que les scripts sont exécutables (par exemple #{chmod 755
-auto/*}#).
-
-#{auto/config}#
-
-code{
-
- #!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-Nous expédions maintenant scripts auto d'exemple avec live-build sur la base
-des exemples ci-dessus. Vous pouvez copier ces comme point de départ.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Editer #{auto/config}#, en changeant ou en ajoutant des options comme bon
-vous semble. Dans l'exemple ci-dessus, #{--packages-lists standard}# est
-fixé à la valeur par défaut. Changez ce à une valeur appropriée pour votre
-image (ou le supprimer si vous voulez utiliser par défaut) et ajouter des
-options supplémentaires dans les lignes de continuation qui suivent.
diff --git a/manual/fr/user_overview.ssi b/manual/fr/user_overview.ssi
deleted file mode 100644
index 1c09740..0000000
--- a/manual/fr/user_overview.ssi
+++ /dev/null
@@ -1,168 +0,0 @@
-:B~ Aperçu des outils
-
-1~overview-of-tools Aperçu des outils
-
-Ce chapitre contient un aperçu des trois principaux outils utilisés dans les
-systèmes de construction Debian Live: live-build, live-boot et live-config.
-
-2~live-build live-build
-
-live-build est une collection de scripts pour construire des systèmes Debian
-Live. Ces scripts sont aussi appelés "commandes".
-
-L'idée derrière live-build est de constituer un cadre qui utilise un
-répertoire de configuration pour automatiser et personnaliser complètement
-tous les aspects de la construction d'une image Live.
-
-Plusieurs concepts sont similaires à celles dans les outils de le paquet
-Debian debhelper écrit par Joey Hess:
-
-_* Les scripts ont un emplacement central pour la configuration de leur
-fonctionnement. Avec debhelper, c'est le sous-répertoire #{debian/}# d'un
-arbre de paquets. Par exemple, dh_install cherchera, entre autres, un
-fichier appelé #{debian/install}# pour déterminer quels fichiers doivent
-exister dans un paquet binaire particulier. De la même manière, live-build
-enregistre son configuration entièrement sous un sous-répertoire
-#{config/}#.
-
-_* Les scripts sont indépendants - c'est-à-dire, il est toujours sûr
-d'exécuter chaque commande.
-
-Contrairement à debhelper, live-build contient un outil pour générer un
-répertoire de configuration de squelette, #{lb config}#. Cela pourrait être
-considéré comme similaire à des outils tels que #{dh-make}#. Pour plus
-d'informations à propos de #{lb config}#, s'il vous plaît voir {La commande
-lb config}#lb-config.
-
-Le reste de cette section examine les trois commandes les plus importantes:
-
-_* *{lb config}*: Responsable de l'initialisation d'un répertoire de
-configuration du système Live. Voir {La commande lb config }#lb-config pour
-plus d'informations.
-
-_* *{lb build}*: Responsable de démarrer un système de construction
-Live. Voir {La commande lb build}#lb-build pour plus d'informations.
-
-_* *{lb clean}*: Responsable pour enlever des parties d'un système de
-construction Live. Voir {La commande lb clean}#lb-clean pour plus
-d'informations.
-
-3~lb-config La commande #{lb config}#
-
-Comme indiqué dans {live-build}#live-build, les scripts qui composent
-live-build lisent leur configuration avec la commande #{source}# à partir
-d'un seul répertoire nommé #{config/}#. Comme la construction de ce
-répertoire à la main serait fastidieux et source d'erreurs, la commande #{lb
-config}# peut être utilisée pour créer des répertoires de configuration de
-squelette.
-
-Exécuter #{lb config}# sans aucun argument crée un sous-répertoire
-#{config/}# dont il remplit avec certains paramètres par défaut:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-L'utilisation de #{lb config}# sans aucun argument serait approprié pour les
-utilisateurs qui ont besoin d'une image de base, ou qui ont l'intention
-d'offrir plus tard, une configuration plus complète via auto/config (voir
-{Gestion d'une configuration}#managing-a-configuration pour plus de
-détails).
-
-Normalement, vous voulez spécifier certaines options. Par exemple, pour
-inclure la liste du paquet «gnome» dans votre configuration:
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-Il est possible de spécifier plusieurs options, telles que:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-Une liste complète des options est disponible dans la page de manuel de
-#{lb_config}#.
-
-3~lb-build La commande #{lb build}#
-
-La commande #{lb build}# lit dans votre configuration à partir du répertoire
-config/. Il exécute alors les commandes de niveau inférieur nécessaires pour
-construire votre système Live.
-
-3~lb-clean La commande #{lb clean}#
-
-Le travail de la commande #{lb clean}# est enlever les différentes parties
-d'une construction afin que autres compilations ultérieures puissent
-commencer à partir d'un état propre. Par défaut, les stades #{chroot}#,
-#{binary}# et #{source}# sont nettoyées, mais la cache est laissé intact. En
-outre, les étapes individuelles peuvent être nettoyées. Par exemple, si vous
-avez effectué des changements qui affectent uniquement la phase binaire,
-utilisez #{lb clean --binary}# avant de construire un nouveau binaire. Voir
-la page de manuel de #{lb_clean}# pour une liste complète des options.
-
-2~live-boot Le paquet live-boot
-
-live-boot est une collection de scripts fournissant hooks pour
-initramfs-tools, utilisé pour générer un initramfs capable de démarrer des
-systèmes live, comme ceux créés par live-build. Cela inclut les ISOs de
-Debian Live, netboot tarballs, et les images clé USB.
-
-Au démarrage il va chercher un support en lecture seule qui contient un
-répertoire «/live» où un système de fichiers racine (souvent une image de
-système de fichiers compressé comme squashfs) est stocké. S'il est trouvé,
-il va créer un environnement accessible en écriture, en utilisant aufs, afin
-que systémes similaires à Debian puissent démarrer à partir de ça.
-
-Plus d'information sur ramfs initial dans Debian peut être trouvé dans le
-Debian Linux Kernel Handbook à http://kernel-handbook.alioth.debian.org/
-dans le chapitre sur initramfs.
-
-2~live-config Le paquet live-config
-
-live-config se compose des scripts qui s'exécutent au démarrage après
-live-boot pour configurer le système live automatiquement. Il gère tâches
-telles que l'établissement du nom d'hôte, paramètres régionaux et le fuseau
-horaire, la création de l'utilisateur live, l'inhibition des cron jobs et
-autologin de l'utilisateur live.
diff --git a/manual/it/_sisu/.empty b/manual/it/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/it/_sisu/image/.empty b/manual/it/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/it/_sisu/sisurc.yml b/manual/it/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/it/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/it/_sisu/skin/doc/skin_debian-live.rb b/manual/it/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/it/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/it/about_manual.ssi b/manual/it/about_manual.ssi
deleted file mode 100644
index d8eef6e..0000000
--- a/manual/it/about_manual.ssi
+++ /dev/null
@@ -1,279 +0,0 @@
-:B~ A proposito di questo manuale
-
-1~about-manual A proposito di questo manuale
-
-L'obiettivo principale di questo manuale è quello di servire come unico
-punto d'accesso per tutta la documentazione relativa al progetto Debian
-Live. Sebbene sia principalmente focalizzato nell'aiutare a costruire un
-sistema live e non su argomenti per l'utente finale, è comunque possibile
-trovare alcune informazioni utili in queste sezioni: le {Nozioni di
-base}#the-basics coprono la preparazione delle immagini da avviare da un
-supporto o dalla rete, mentre {Personalizzare i comportamenti durante
-l'esecuzione}#customizing-run-time-behaviours descrive alcune opzioni
-specificabili al prompt d'avvio, come la scelta di un layout di tastiera e
-una lingua, e l'utilizzo della persistenza.
-
-Alcuni dei comandi menzionati nel testo devono essere eseguiti con i
-privilegi di super-utente che possono essere ottenuti diventando utente root
-tramite #{su}# oppure usando #{sudo}#. Per distinguere i comandi che possono
-essere eseguiti come utente normale da quelli che necessitano dei privilegi
-di super-utente, i comandi sono preceduti rispettivamente da #{$}# o
-#{#}#. Questi simboli non fanno parte del comando.
-
-2~ Per gli impazienti
-
-Sebbene crediamo che ogni cosa in questo manuale sia importante almeno per
-alcuni dei nostri utenti, ci rendiamo conto che c'è tanto materiale da
-trattare e che si potrebbe voler provare il software prima di entrare nei
-dettagli. Pertanto, abbiamo messo a disposizione nella sezione
-{Esempi}#examples tre tutorial progettati per insegnarvi le basi della
-costruzione e della personalizzazione delle immagini. Si legga innanzitutto
-{Usare gli esempi}#using-the-examples, seguito da {Tutorial 1: un'immagine
-standard}#tutorial-1, {Tutorial 2: un programma di utilità web
-browser}#tutorial-2 e, infine, {Tutorial 3: un'immagine
-personalizzata}#tutorial-3. Alla fine di queste esercitazioni, si avrà un
-assaggio di ciò che si può fare con Debian Live. Ti invitiamo ad uno studio
-più approfondito del manuale, magari leggendo in seguito le {Nozioni di
-base}#the-basics, sfogliando o saltando {Creare un'immagine
-netboot}#building-netboot-image, e finendo con la lettura di {Panoramica
-sulla personalizzazione}#customization-overview e dei capitoli che lo
-seguono. A questo punto, ci auguriamo che tu sia davvero eccitato da ciò che
-si può fare con Debian Live e motivato a leggere il resto del manuale, da
-cima a fondo.
-
-2~terms Glossario
-
-_* *{Live system}*: Un sistema operativo che può partire senza installazione
-su disco rigido. I sistemi live non alterano né il sistema operativo locale
-(o i sistemi operativi locali) né i file già installati sul disco rigido del
-computer a meno che lo si faccia volontariamente. I sistemi live vengono
-solitamente avviati da supporti quali CD, DVD o penne USB; alcuni possono
-anche avviarsi via rete.
-
-_* *{Debian Live}*: Il sotto-progetto Debian che mantiene i pacchetti
-live-boot, live-build, live-config e live-manual.
-
-_* *{Debian Live system}*: Un sistema live che usa software proveniente dal
-sistema operativo Debian e che può essere lanciato da CD, DVD, supporti USB,
-via rete (tramite immagini netboot) e via internet (tramite il parametro di
-boot #{fetch=URL}#).
-
-_* *{Host system}*: L'ambiente utilizzato per creare il sistema live.
-
-_* *{Target system}*: L'ambiente usato per eseguire il sistema live.
-
-_* *{live-boot}*: Una raccolta di script usati per avviare sistemi
-live. live-boot era una parte di live-initramfs.
-
-_* *{live-build}*: Una raccolta di script usati per creare sistemi Debian
-Live personalizzati. live-build era conosciuto come live-helper, ed ancora
-prima come live-package.
-
-_* *{live-config}*: Una raccolta di script usati per configurare un sistema
-live durante il processo di inizializzazione. live-config era una parte di
-live-initramfs.
-
-_* *{live-manual}*: Questo documento è inserito nel pacchetto chiamato
-live-manual.
-
-_* *{Debian Installer (d-i)}*: Il sistema d'installazione ufficiale per la
-distribuzione Debian.
-
-_* *{Boot parameters}*: Parametri che possono essere immessi nel prompt del
-boot loader per modificare il comportamento del kernel o di live-config.
-
-_* *{chroot}*: Il programma chroot, #{chroot(8)}#, rende possibile eseguire
-diverse istanze dell'ambiente GNU/Linux su un singolo sistema
-simultaneamente senza riavviare.
-
-_* *{Binary image}*: Un file che contiene il sistema live, come binary.iso o
-binary.img.
-
-_* *{Target distribution}*: La distribuzione su cui sarà basato il sistema
-live. Può differire dalla distribuzione presente sul proprio computer.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Nomi in codice per i
-rilasci Debian; al momento Squeeze è l'attuale *{stable}* e Wheezy l'attuale
-*{testing}*. Sid sarà sempre il sinonimo della *{unstable}*. In tutto il
-manuale si tende ad usare i nomi in codice dei rilasci, in quanto questo è
-ciò che è previsto dagli strumenti stessi.
-
-La distribuzione *{stable}* contiene l'ultima distribuzione ufficialmente
-rilasciata da Debian; la *{testing}* è il punto di raccolta per i pacchetti
-della prossima *{stable}*. Uno dei principali vantaggi nell'uso di questa
-distribuzione sta nell'avere software più recente rispetto alla
-*{stable}*. La distribuzione *{unstable}* è dove avviene lo sviluppo attivo
-di Debian; viene generalmente usata dagli sviluppatori o da coloro che amano
-l'azzardo.
-
-2~ Autori
-
-Lista degli autori (in ordine alfabetico):
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Contribuire a questo documento
-
-Questo manuale è pensato come un progetto comunitario e ogni suggerimento e
-contributo è benvenuto. Il modo migliore per apportare un contributo è di
-inviarlo alla mailing list. Per maggiori informazioni si veda la sezione
-{Contatti}#contact.
-
-Quando si sottopone un contributo, si prega di indicare chiaramente il
-detentore del copyright e di includere la licenza. Si noti che, per essere
-accettato, il contributo deve essere distribuito con la stessa licenza del
-resto del documento, ovvero la GPL versione 3 o successiva.
-
-I sorgenti di questo manuale sono mantenuti utilizzando il sistema di
-controllo Git. Si può visionare la copia più recente eseguendo:
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Prima di sottoporre un contributo, si prega di visionare l'anteprima del
-proprio lavoro. Per ottenere l'anteprima di live-manual, assicurarsi di
-avere installati i pacchetti necessari per la sua compilazione eseguendo:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-Si può compilare il live-manual dalla directory superiore del checkout di
-Git eseguendo:
-
-code{
-
- $ make build
-
-}code
-
-Dato che occorre del tempo per compilare il manuale in tutte le lingue
-supportate, può risultare conveniente farlo per una sola lingua, ad esempio
-eseguendo:
-
-code{
-
- $ make build LANGUAGES=en
-
-}code
-
-3~ Applicare le patch
-
-Chiunque può eseguire il commit direttamente sul repository; tuttavia
-chiediamo di inviare le modifiche più corpose in mailing list, per poterne
-prima discuterne. Per eseguire il push sul repository, si deve seguire
-questa procedura:
-
-_* Prelevare la chiave pubblica:
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Aggiungere la seguente sezione alla propria configurazione di
-openssh-client:
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Scaricare tramite ssh un clone del manuale:
-
-code{
-
- $ git clone git at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Si noti che tutte le modifiche vanno eseguite sul ramo debian-next e non
-su quello debian.
-
-_* Dopo aver modificato i file in #{manual/en/}#, chiamare il target
-"commit" nella directory superiore per bonificare i file ed aggiornare i
-file di traduzione:
-
-code{
-
- $ make commit
-
-}code
-
-_* Dopo la pulizia è possibile eseguire il commit delle modifiche. Si
-scrivano messaggi costituiti da frasi in inglese esaurienti ed utili,
-inizianti con una lettera maiuscola e terminanti con un punto. Solitamente
-cominceranno con la forma "Fixing/Adding/Removing/Correcting/Translating",
-ad esempio.
-
-code{
-
- $ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Inviare il commit al server:
-
-code{
-
- $ git push
-
-}code
-
-3~ Traduzione
-
-Per inviare una traduzione per una nuova lingua, seguire questi tre passi:
-
-_* Tradurre i file about_manual.ssi.pot, about_project.ssi.pot e
-index.html.in.pot nella propria lingua con il proprio editor preferito (tipo
-poedit). Inviare i file tradotti alla mailing list. Una volta che abbiamo
-ricevuto il contributo, aggiungeremo la nuova lingua al manuale (fornendo i
-file po) e la attiveremo per la procedura di compilazione automatica.
-
-_* Una volta che la nuova lingua è stata aggiunta, si può iniziare a
-tradurre tutti i file po situati in #{manual/po/}#, nell'ordine che si
-preferisce.
-
-_* Non si dimentichi che è necessario dare un #{make commit}# per
-assicurarsi che i manuali tradotti siano aggiornati partendo dai file po,
-prima di #{git commit -a}# e #{git push}#.
diff --git a/manual/it/about_project.ssi b/manual/it/about_project.ssi
deleted file mode 100644
index 21a1b81..0000000
--- a/manual/it/about_project.ssi
+++ /dev/null
@@ -1,110 +0,0 @@
-:B~ A proposito del progetto Debian Live
-
-1~about-project A proposito del progetto Debian Live
-
-2~ Motivazioni
-
-3~ Cosa c'è di sbagliato con gli attuali sistemi live
-
-Quando Debian Live iniziò erano disponibili svariati sistemi live basati su
-Debian che tuttora stanno facendo un buon lavoro. Dal punto di vista di
-Debian molti di essi hanno uno o più dei seguenti svantaggi:
-
-_* Non sono progetti Debian, per cui non sono supportati da Debian.
-
-_* Mischiano differenti distribuzioni come ad esempio: *{testing}* e
-*{unstable}*.
-
-_* Supportano solamente i386.
-
-_* Modificano l'aspetto e il comportamento dei pacchetti snellendoli per
-risparmiare spazio.
-
-_* They include packages from outside of the Debian archive.
-
-_* Forniscono un kernel con patch addizionali che non appartengono a Debian.
-
-_* Sono grandi e lenti a causa delle loro dimensioni e non adatti per
-operazioni di salvataggio.
-
-_* Non sono disponibili in diversi formati come CD, DVD, penne USB e
-immagini netboot.
-
-3~ Perché creare il proprio sistema live?
-
-Debian è il Sistema Operativo Universale: ha un sistema live per mostraree
-rappresentare accuratamente il sistema con i seguenti vantaggi:
-
-_* Sarebbe un sottoprogetto di Debian.
-
-_* Riflette lo stato (attuale) di una distribuzione.
-
-_* Gira su più architetture possibili.
-
-_* È costituito solo da pacchetti Debian non modificati.
-
-_* Non contiene nessun pacchetto che non sia presente nell'archivio di
-Debian.
-
-_* Usa un kernel Debian inalterato senza patch addizionali.
-
-2~ Filosofia
-
-3~ Solamente pacchetti da Debian "main", inalterati.
-
-Verranno usati solo pacchetti dal repository Debian della sezione "main".La
-sezione non-free non è parte di Debian perciò non possono essere
-affattousati per le immagini ufficiali del sistema live.
-
-Non verrà cambiato nessun pacchetto. Nel caso in cui sarà necessario
-cambiare qualcosa sarà fatto in coordinazione con il maintainer del
-pacchetto Debian.
-
-In via eccezionale i nostri pacchetti come live-boot, live-build o
-live-config possono temporaneamente essere usati dal nostro repository per
-ragioni di sviluppo (ad esempio per creare istantanee). Verranno caricati
-regolarmente in Debian.
-
-3~ Nessun pacchetto di configurazione per il sistema live
-
-In questa fase non saranno disponibili né esempi di installazione né
-configurazioni alternative. Tutti i pacchetti vengono usati con la loro
-configurazione predefinita così come accade con una regolare installazione
-di Debian.
-
-Nel caso in cui serva una configurazione predefinita differente, sarà fatto
-in coordinazione con il maintainer del pacchetto in Debian.
-
-Viene fornito un sistema per configurare i pacchetti tramite debconf nel
-#{lb config}# (use --preseed FILE) consentendo di installare pacchetti
-configurati secondo le proprie preferenze nell'immagine Debian Live
-personalizzata, ma per le immagini ufficiali verrà usata la configurazione
-predefinita. Per ulteriori informazioni si veda {Panoramica sulla
-personalizzazione}#customization-overview.
-
-Eccezione: ci sono alcuni cambiamenti essenziali per far nascere un sistema
-live (ad esempio configurare pam per permettere le password vuote). Queste
-modifiche essenziali devono essere tenute al minimo possibile e saranno
-eventualmente aggiunte ai repository Debian.
-
-2~contact Contatti
-
-_* *{Mailing list}*: Il principale contatto del progetto è la mailing list
-http://lists.debian.org/debian-live/, si possono inviare email alla lista
-direttamente a debian-live at lists.debian.org. Gli archivi sono disponibili
-presso http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: Molti utenti e sviluppatori sono presenti sul canale
-#debian-live su irc.debian.org (OFTC). Quando si pone una domanda su IRC, si
-prega di essere pazienti nell'ottenere una risposta; se non si riceve
-risposta scrivere alla mailing list.
-
-_* *{BTS}*: Il Debian Bug Tracking System (BTS) contiene i dettagli dei bug
-riportati dagli utenti e dagli sviluppatori. A ciascun bug viene assegnato
-un numero, e viene mantenuto finché non è segnato come risolto. Per
-ulteriori informazioni si veda {Segnalare bug}#bugs.
-
-_* *{Wiki}*: Il wiki di Debian Live all'indirizzo
-http://wiki.debian.org/DebianLive è un posto dove raccogliere informazioni,
-discutere di tecnologie applicate e documenti sull'infrastruttura dei
-sistemi Debian Live che vanno oltre lo scopo di questo manuale.
diff --git a/manual/it/index.html.in b/manual/it/index.html.in
deleted file mode 100644
index c52644f..0000000
--- a/manual/it/index.html.in
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-
-<head>
- <title>Progetto Debian Live</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Manuale Debian Live</h2>
-
- <p>
- Si prega di segnalare errori, omissioni, patch e suggerimenti sulla nostra
-mailing list <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>
-e leggere <a href="html/about-manual.html#how-to-contribute">come
-contribuire</a> al manuale.
- </p>
-
- <h3>Formati disponibili</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">multi-pagina</a>, <a
-href="html/live-manual.html">pagina unica</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 verticale</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 orizzontale</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">lettera verticale</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">lettera orizzontale</a></li>
- <li><a href="txt/live-manual.txt">Testo semplice</a></li>
- </ul>
-
- <p>
- Ultima modifica: @DATE_CHANGE@<br />
- Ultima compilazione: @DATE_BUILD@
- </p>
-
- <h3>Sorgente</h3>
-
- <p>
- I sorgenti di questo manuale sono disponibili nel repository <a
-href="http://git.or.cz/">Git</a> su live.debian.net.
- </p>
-
- <ul>
- <li>Sfoglia: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Note legali</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/it/live-manual.ssm b/manual/it/live-manual.ssm
deleted file mode 100644
index 5c44a50..0000000
--- a/manual/it/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Manuale di Debian Live
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: Questo programma è software libero: è possibile ridistribuirlo e modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation, sia la versione 3 della licenza o (a scelta) una versione successiva.<br><br>Questo programma è distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA, nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedere la GNU General Public License per ulteriori dettagli.<br><br>Si dovrebbe aver ricevuto una copia della GNU General Public License con questo programma. In caso contrario, vedere http://www.gnu.org/licenses/. <br><br>Il testo completo della GNU General Public License può essere trovato nel file /usr/share/common-licenses/GPL-3.
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ A proposito
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ Utente
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Progetto
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Esempi
-
-<< user_examples.ssi
diff --git a/manual/it/project_bugs.ssi b/manual/it/project_bugs.ssi
deleted file mode 100644
index 3f32eaf..0000000
--- a/manual/it/project_bugs.ssi
+++ /dev/null
@@ -1,204 +0,0 @@
-B~ Segnalare bug
-
-1~bugs Segnalare bug
-
-Debian Live è lungi dall'essere perfetta, ma con il vostro aiuto vogliamo
-avvicinarci il più possibile a questo livello. Non esitare a segnalare un
-bug: è meglio compilare un rapporto due volte che mai. Questo capitolo
-include alcune raccomandazioni su come presentare una buona segnalazione.
-
-Per gli impazienti
-
-_* Per i problemi noti verificare sempre lo stato degli aggiornamenti
-dell'immagine sulla nostra pagina iniziale http://live.debian.net/.
-
-_* Prima di inviare una segnalazione di bug provare a riprodurlo con le
-*{versione più recenti}* di live-build, live-boot e live-config.
-
-_* Si cerchi di fornire *{informazioni il più dettagliate possibile}*
-riguardo il bug. Questo comprende (almeno) la versione di live-build,
-live-boot e live-config utilizzata e la distribuzione del sistema live che
-si sta costruendo.
-
-2~ Problemi noti
-
-Giacché Debian *{testing}* e Debian *{unstable}* subiscono cambiamenti
-continui, quando si specifica l'una o l'altra come sistema di destinazione,
-può non essere sempre possibile una creazione che vada a buon fine.
-
-% FIXME:
-
-Se questo causa troppe difficoltà, non creare un sistema basato su
-*{testing}* o *{unstable}* ma usare piuttosto *{stable}*. live-build si basa
-su *{stable}* in modo predefinito.
-
-I problemi noti al momento sono elencati sotto la sezione "status" della
-nostra pagina iniziale http://live.debian.net/
-
-Questo manuale non intende insegnare come identificare e risolvere
-correttamente i problemi dei pacchetti delle distribuzioni di sviluppo,
-tuttavia ci sono un paio di cose da provare: se la creazione di *{testing}*
-non va a buon fine provare con *{unstable}*; se non funziona nemmeno
-*{unstable}* tornare a *{testing}* ed effettuare il pinning da *{unstable}*
-alla nuova versione del pacchetto corrotto (si veda {APT
-pinning}#apt-pinning per i dettagli).
-
-2~ Ricostruire da zero
-
-Per essere certi che un particolare bug non sia causato dalla creazione di
-un sistema non pulito, ricostruire sempre l'intero sistema da zero per
-vedere se il bug sia riproducibile.
-
-2~ Usare pacchetti aggiornati
-
-L'utilizzo di pacchetti datati può causare notevoli complicazioni nel
-tentativo di riprodurre (e alla fine risolvere) il problema. Assicurarsi che
-il sistema creato sia aggiornato e ogni pacchetto incluso nell'immagine lo
-sia a sua volta.
-
-2~collect-information Raccogliere informazioni
-
-Nella segnalazione si invita a fornire informazioni sufficienti. Dovrebbe
-almeno contenere l'esatta versione di live-build nella quale si è trovato il
-bug e i passi per riprodurlo. Con un po' di buon senso si può includere
-qualsiasi altro dettaglio rilevante che si ritiene utile per la risoluzione
-del problema.
-
-Affinché la segnalazione del bug sia migliore possibile, si richiedono
-almeno le seguenti informazioni:
-
-_* Architettura del sistema ospitante
-
-_* Versione di live-build sul sistema ospitante
-
-_* Versione di live-boot sul sistema ospitante
-
-_* Versione di live-config sul sistema live
-
-_* Versione di #{debootstrap}# o #{cdebootstrap}# sul sistema ospitante
-
-_* Architettura del sistema live
-
-_* Distribuzione del sistema live
-
-_* Versione del kernel sul sistema live
-
-È possibile generare un registro del processo di costruzione usando il
-comando #{tee}#. Si raccomanda di farlo automaticamente con uno script
-#{auto/build}#; (si veda {Gestire una
-configurazione}#managing-a-configuration per i dettagli).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-All'avvio, live-boot conserva un registro in #{/var/log/live.log}# (or
-#{/var/log/live-boot.log}#).
-
-Inoltre, per escludere altri errori, è sempre una buona idea creare un tar
-della propria directory #{config/}# e caricarlo da qualche parte (*{non}*
-inviarlo come allegato alla mailing list), in modo che sia per noi possibile
-riprodurre gli errori incontrati. Se ciò causa problemi (ad esempio a causa
-della dimensione) si può utilizzare l'output di #{lb config --dump}# che
-produce un sommario dell'albero di configurazione (elenca i file nelle
-sottodirectory di #{config/}# ma non le include).
-
-Ricordarsi che i file di registro da inviare vanno creati con l'impostazione
-della lingua inglese, ad esempio eseguendo il comando live-build preponendo
-#{LC_ALL=C}# oppure #{LC_ALL=en_US}#.
-
-2~ Se possibile isolare il caso non andato a buon fine
-
-Se possibile, isolare il caso non andato a buon fine alla variazione più
-piccola che lo causa. Non è sempre facile da fare, perciò non preoccupatevi
-se non riuscite a gestirlo per la vostra segnalazione. Tuttavia, se si
-pianifica bene il ciclo di sviluppo adottando piccole modifiche per ogni
-iterazione, si riuscirà ad isolare il problema creando una configurazione
-semplificata che si avvicina all'attuale con l'aggiunta delle sole modifiche
-problematiche. Se si incontrano serie difficoltà nel trovare la causa,
-potrebbe essere che sono stati inseriti troppi cambiamenti in una sola volta
-e bisogna cambiare approccio.
-
-2~ Segnalare il bug del pacchetto giusto
-
-Dove appare il bug?
-
-3~ Durante la compilazione mentre esegue il bootstrap
-
-live-build avvia inizialmente un sistema Debian di base con #{debootstrap}#
-o #{cdebootstrap}#; può fallire a seconda dello strumento utilizzato e della
-distribuzione Debian che si sta avviando. Se il bug appare a questo punto
-controllare che l'errore sia relativo ad uno specifico pacchetto Debian (più
-probabile) o allo strumento di avvio stesso.
-
-In entrambi i casi non è un bug in Debian Live, ma piuttosto in Debian
-stessa che non può essere risolto direttamente. Si prega di inviare una
-segnalazione di bug riguardo l'utilità di avvio o il pacchetto che ha
-fallito.
-
-3~ Durante la compilazione mentre installa i pacchetti
-
-live-build installa pacchetti aggiuntivi dall'archivio Debian e può fallire
-a seconda della distribuzione Debian e lo stato dell'archivio giornaliero.Se
-il bug appare a questo punto, controllare che l'errore sia riproducibile su
-un sistema normale.
-
-In questo caso non è un bug in Debian Live, ma piuttosto in Debian, inviare
-una segnalazione sul pacchetto che ha fallito. Si otterranno maggiori
-informazioni eseguendo #{debootstrap}# separatamente dal sistema live o
-eseguendo #{lb bootstrap --debug}#.
-
-Se si verifica un problema utilizzando un mirror locale o un qualsiasi tipo
-di proxy è bene riprodurlo avviando da un mirror ufficiale.
-
-3~ In fase di avvio
-
-Se l'immagine non si avvia segnalarlo alla mailing list con le informazioni
-richieste in {Raccogliere informazioni}#collect-information. Non dimenticare
-di menzionare come e quando l'immagine fallisce, in Qemu, VMWare o hardware
-reale. Se si utilizza un qualsiasi sistema di virtualizzazione provare
-sempre su hardware reale prima di segnalare un bug; anche fornire
-un'istantanea dello schermo può essere molto utile.
-
-3~ In fase di esecuzione
-
-Se un pacchetto è stato installato con successo ma fallisce durante
-l'esecuzione del sistema live, si tratta probabilmente di un bug in Debian
-Live. Tuttavia,
-
-2~ Fare la ricerca
-
-Prima di riportare il bug si prega di cercare sul web il messaggio d'errore
-o il sintomo ottenuti. Poiché è altamente improbabile essere l'unica persona
-ad incontrare un certo problema, c'è sempre la possibilità che sia stato
-discusso altrove e che siano stati proposte una soluzione, una patch o
-soluzione temporanea.
-
-Si dovrebbe prestare particolare attenzione alla mailing list di Debian Live
-così come la pagina iniziale del sito, in quanto contengono informazioni più
-aggiornate. Se tale informazione esiste si includa sempre un riferimento
-nella segnalazione del bug.
-
-In aggiunta bisogna controllare l'attuale elenco dei bug riguardanti
-live-build, live-boot e live-config per vedere se sia già stato segnalato
-qualcosa di simile.
-
-2~ Dove segnalare i bug
-
-Il progetto Debian Live tiene traccia di tutti i bug sul Debian Bug Tracking
-System (BTS, sistema di tracciamento dei bug Debian), si veda
-http://bugs.debian.org/ per le informazioni su come usarlo. È anche
-possibile utilizzare il comando #{reportbug}# dall'omonimo pacchetto.
-
-In genere bisogna riportare gli errori in fase di compilazione verso il
-pacchetto live-build, quelli di avvio verso live-boot e quelli in fase di
-esecuzione a live-config. Se non siete certi di quale sia il pacchetto
-appropriato o serve maggiore aiuto prima della segnalazione, inviate un
-messaggio in mailing list e vi aiuteremo a capire.
-
-Si noti che i bug trovati nelle distribuzioni derivate da Debian (come
-Ubuntu e altre) *{non}* vanno segnalati a Debian BTS a meno che non siano
-riproducibili anche su un sistema Debian utilizzando pacchetti ufficiali
-Debian.
diff --git a/manual/it/project_coding-style.ssi b/manual/it/project_coding-style.ssi
deleted file mode 100644
index 618b287..0000000
--- a/manual/it/project_coding-style.ssi
+++ /dev/null
@@ -1,148 +0,0 @@
-B~ Lo stile nello scrivere codice
-
-1~coding-style Lo stile nello scrivere codice
-
-Questo capitolo documenta lo stile usato per il codice di live-boot e gli
-altri.
-
-2~ Compatibilità
-
-_* Non usare sintassi o semantiche mirate alla shell Bash. Ad esempio, l'uso
-di costrutti array.
-
-_* Utilizzare solo il sottoinsieme POSIX - ad esempio, usare $(foo) invece
-di `foo`.
-
-_* È possibile verificare i propri script con "sh -n" e "checkbashisms".
-
-2~ Rientri
-
-_* Usare sempre i tab piuttosto che gli spazi.
-
-2~ Ritorno a capo
-
-_* Generalmente le righe sono composte da un massimo di 80 caratteri.
-
-_* Utilizzare lo "stile Linux" per le interruzioni di riga:
-
-Sbagliato:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Corretto:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* Lo stesso vale per le funzioni:
-
-Sbagliato:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Corretto:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variabili
-
-_* Le variabili vanno sempre scritte in maiuscolo.
-
-_* Le variabili usate in #{lb config}# iniziano sempre con il prefisso
-#{LB_}#.
-
-_* Le variabili interne temporanee in live-build dovrebbero iniziare con il
-prefisso #{\_LB_}#.
-
-_* Le variabili locali iniziano con il prefisso live-build #{\_\_LB_}#.
-
-_* Le variabili in live-config relative ai parametri di avvio iniziano con
-#{LIVE_}#.
-
-_* Tutte le altre variabili in live-config iniziano con il prefisso #{_}#.
-
-_* Intorno alle variabili utilizzare le graffe; ad esempio scrivere
-#{${FOO}}# invece di #{$FOO}#.
-
-_* Proteggere sempre le variabili con le virgolette per rispettare
-potenziali spaziature: scrivere #{"${FOO}"}# e non #{${FOO}}#.
-
-_* Per ragioni di coerenza, usare sempre le virgolette quando si assegnano
-valori alle variabili:
-
-Sbagliato:
-
-code{
-
- FOO=bar
-
-}code
-
-Corretto:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* Utilizzando variabili multiple, quotare l'intera espressione:
-
-Sbagliato:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Corretto:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Varie
-
-_* Per le chiamate a sed utilizzare "#{|}#" (senza virgolette intorno) come
-separatore, ad esempio "#{sed -e 's|foo|bar|'}#" (senza "").
-
-_* Non utilizzare il comando #{test}# per prove o confronti, usare "#{[}#"
-"#{]}#" (senza ""); ad esempio "#{if [ -x /bin/foo ]; ...}#" e non "#{if
-test -x /bin/foo; ...}#".
-
-_* Ove possibile utilizzare #{case}# invece di #{test}#, essendo più facile
-da leggere e più veloce in esecuzione.
diff --git a/manual/it/project_procedures.ssi b/manual/it/project_procedures.ssi
deleted file mode 100644
index 334c2d8..0000000
--- a/manual/it/project_procedures.ssi
+++ /dev/null
@@ -1,142 +0,0 @@
-B~ Procedure
-
-1~procedures Procedure
-
-Questo capitolo documenta le procedure all'interno del progetto Debian Live
-per vari compiti che necessitano di cooperazione con altri team Debian.
-
-2~ Aggiornamenti degli udeb
-
-Prima di effettuare dei commit di un udeb nel repository svn
-dell'installatore Debian va eseguito:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Rilasci importanti
-
-Rilasciare una nuova versione stabile di Debian implica che molti team
-differenti lavorino insieme; ad un certo punto si inserisce il team Live che
-prepara le immagini del sistema live. I requisiti per fare ciò sono:
-
-_* Un mirror contenente le versioni rilasciate per l'archivio debian,
-debian-security e debian-volatile al quale possa accedere il debian-live
-buildd.
-
-_* Vanno resi noti i nomi dell'immagine
-(debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* Le liste dei pacchetti devono essere state aggiornate.
-
-_* Bisogna sincronizzare i dati dal cd Debian (udeb esclude le liste).
-
-_* Bisogna sincronizzare i file inclusi dal cd Debian (README.*, doc/*,
-ecc.).
-
-_* Le immagini vengono create e ospitate su cdimage.debian.org.
-
-2~ Rilasci minori
-
-_* Bisogna nuovamente aggiornare i mirror di debian, debian-security e
-debian-volatile.
-
-_* Le immagini vengono create e ospitate su cdimage.debian.org.
-
-_* Inviare email di annuncio.
-
-3~ Modello per l'annuncio di un rilascio minore.
-
-Si può generare un'email per l'annuncio dei rilasci minori usando il modello
-sottostante e il seguente comando:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-Si prega di controllare attentamente l'email prima di inviarla e passarla ad
-altri per le correzioni.
-
-code{
-
- Debian Live images for Debian GNU/Linux %major% updated
-
- The Debian Live project is pleased to announce the availability of
- updated Live images for its stable distribution Debian GNU/Linux %major%
- (codename "%codename%").
-
- The images are available for download at:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- This update incorporates the changes made in the %minor% point release,
- which adds corrections for security problems to the stable release
- along with a few adjustments for serious problems. A full list of the
- changes may be viewed at:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
- It also includes the following Live-specific changes:
-
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
-
-
- URLs
- ----
-
- Download location of updated images:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Debian Live project homepage:
-
- <http://live.debian.net/>
-
- The current stable distribution:
-
- <http://ftp.debian.org/debian/dists/stable>
-
- stable distribution information (release notes, errata etc.):
-
- <http://www.debian.org/releases/stable/>
-
- Security announcements and information:
-
- <http://www.debian.org/security/>
-
-
- About Debian
- -------------
-
- The Debian Project is an association of Free Software developers who
- volunteer their time and effort in order to produce the completely free
- operating system Debian GNU/Linux.
-
-
- About Debian Live
- -----------------
-
- Debian Live is an official sub-project of Debian which produces Debian
- systems that do not require a classical installer. Images are available
- for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
- filesystem images for booting directly from the internet.
-
-
- Contact Information
- -------------------
-
- For further information, please visit the Debian Live web pages at
- <http://live.debian.net/> or alternatively send mail to
- <debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/it/user_basics.ssi b/manual/it/user_basics.ssi
deleted file mode 100644
index 6acf0af..0000000
--- a/manual/it/user_basics.ssi
+++ /dev/null
@@ -1,549 +0,0 @@
-:B~ Nozioni di base
-
-1~the-basics Nozioni di base
-
-Questo capitolo contiene una breve panoramica del processo di generazione e
-le istruzioni per utilizzare i tre tipi di immagine più comunemente
-utilizzati. La tipologia di immagine più versatile, #{iso-hybrid}#, può
-essere usata su una macchina virtuale, supporto ottico o dispositivo di
-archiviazione portatile USB. In alcuni casi particolari, come l'utilizzo
-della persistenza, la #{usb-hdd}# potrebbe essere più adatta per i
-dispositivi USB. Il capitolo termina con le istruzioni per costruire e usare
-un'immagine di tipo #{net}#, che è un poco più complessa a causa del setup
-richiesto sul server. Si tratta di un argomento leggermente avanzato per chi
-non ha familiarità con l'avvio da rete, ma è incluso qui perché, una volta
-che il setup è stato fatto, è un modo molto comodo per collaudare e
-distribuire immagini facendo il boot nella rete locale senza la seccatura di
-doversi occupare dei mezzi di divulgazione dell'immagine.
-
-Throughout the chapter, we will often refer to the default filenames
-produced by live-build. If you are downloading a prebuilt image instead, the
-actual filenames may vary.
-
-2~what-is-live Che cos'è un sistema live?
-
-Per sistema live generalmente si intende un sistema operativo che può essere
-avviato da un supporto rimovibile, come un CD-ROM o una chiavetta USB oppure
-da una rete, pronto per l'uso senza alcuna installazione su hard disk con
-una configurazione automatica fatta durante l'esecuzione (vedere
-{Glossario}#terms).
-
-Con Debian Live, si tratta di un sistema operativo Debian GNU/Linux,
-generato per una delle architetture previste (attualmente amd64, i386,
-powerpc e sparc). È costituito dalle seguenti parti:
-
-_* *{Immagine del kernel Linux}*, comunemente chiamata #{vmlinuz*}#
-
-_* *{Initial RAM disk image (initrd)}*: un disco RAM creato per il boot di
-Linux, contenente i moduli potenzialmente necessari per montare l'immagine
-di sistema e alcuni script per farlo.
-
-_* *{Immagine di sistema}*: l'immagine del filesystem del sistema
-operativo. Normalmente è usato un filesystem compresso SquashFS, per
-minimizzare le dimensioni dell'immagine Debian Live. Si noti che è in sola
-lettura. Dunque, durante il boot il sistema Debian Live userà un disco RAM e
-il meccanismo 'unione' per attivare i file in scrittura all'interno del
-sistema in esecuzione. Ad ogni modo, tutte le modifiche verranno perse con
-lo spegnimento a meno che non si usi la persistenza opzionale (si veda
-{Persistenza}#persistence).
-
-_* *{Bootloader}*: una piccola porzione di codice predisposto per l'avvio
-dal supporto scelto, che presenta un prompt o un menu per la selezione di
-opzioni/configurazioni. Carica il kernel Linux ed il suo initrd da eseguire
-con un filesystem associato. Possono essere usate diverse soluzioni, in base
-al supporto di destinazione ed al formato del filesystem contenenti le
-componenti precedentemente citate: isolinux per il boot da CD o DVD nel
-formato ISO9660, syslinux per supporti HDD o USB che si avviano da una
-partizione VFAT, extlinux per le partizioni ext/2/3/4 e btrfs, pxelinux per
-il netboot PXE, GRUB per partizioni ext2/3/4, ecc.
-
-È possibile usare live-build per creare l'immagine di sistema secondo le
-proprie specifiche, scegliere un kernel Linux, il suo initrd ed un
-bootloader per avviarli, tutto in un unico formato che dipende dal mezzo
-(immagini ISO9660, immagine disco, ecc.)
-
-2~building-iso-hybrid Primi passi: creare un'immagine ISO ibrida
-
-Indipendentemente dal tipo di immagine, per crearne una è necessario
-eseguire ogni volta la stessa procedura. Come primo esempio si eseguirà la
-seguente sequenza di comandi di live-build per creare un'immagine ISO ibrida
-di base contenente soltanto il sistema Debian standard senza X.org. È adatta
-per essere masterizzata su CD o DVD e anche per essere copiata su una penna
-USB.
-
-In primo luogo eseguire il comando #{lb config}#, il quale creerà una
-gerarchia "config/" nella directory corrente e che verrà utilizzata da altri
-comandi:
-
-code{
-
- $ lb config
-
-}code
-
-Non viene passato alcun parametro a #{lb config}#, in modo da utilizzare le
-impostazioni predefinite per le varie opzioni, vedere {Il comando lb
-config}#lb-config) per maggiori dettagli.
-
-Ora che si ha una gerarchia "config/" si può generare l'immagine con il
-comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-Questo processo può richiedere tempo, a seconda della velocità della
-connessione di rete. Una volta completato, nell'attuale directory ci sarà un
-file immagine #{binary-hybrid.iso}# pronto da usare.
-
-2~using-iso-hybrid Utilizzare un'immagine ISO live ibrida
-
-Dopo aver costruito o scaricato un'immagine ISO ibrida, ottenibile
-all'indirizzo http://www.debian.org/CD/live/, il passo successivo è
-preparare il supporto per l'avvio, che sia esso un CD-R(W), un DVD-R(W) o
-una penna USB.
-
-3~burning-iso-image Masterizzare un'immagine ISO su un supporto fisico
-
-Burning an ISO image is easy. Just install wodim and use it from the
-command-line to burn the image. For instance:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copiare un'immagine ISO ibrida su una penna USB
-
-Le immagini ISO preparate con il comando #{isohybrid}#, come quelle prodotte
-in modo predefinito da #{iso-hybrid}#, possono essere semplicemente copiate
-su una penna USB con il programma #{dd}# o suo equivalente. Inserire una
-penna USB con una dimensione sufficiente a contenere l'immagine e
-determinare quale device sia, al quale in seguito si farà riferimento come
-#{${USBSTICK}}#.Questo è il device della penna, ad esempio #{/dev/sdb}#, non
-una partizione come #{/dev/sdb1}#! È possibile trovare il nome corretto
-controllando l'output di #{dmesg}# una volta inserita, o meglio ancora con
-il comando #{ls -l /dev/disk/by-id}#.
-
-Una volta che si è certi sul nome del device, usare il comando #{dd}# per
-copiare l'immagine sulla penna. *{Questo sovrascriverà qualsiasi dato
-presente su di essa!}*
-
-code{
-
- $ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Avviare il supporto live
-
-La prima volta che si avvia il supporto live, CD, DVD, penna USB o PXE, può
-essere necessario impostare il BIOS del computer, ma giacché questi variano
-parecchio in opzioni e scorciatoie, non siamo in grado di
-descriverli. Alcuni BIOS offrono un menu per selezionare il device in fase
-di boot, in caso sia disponibile nel vostro sistema è il modo più
-semplice. Altrimenti è necessario accedere alla sua configurazione e
-modificare l'ordine di avvio per posizionare la periferica di boot del
-sistema live prima di quella usuale.
-
-Avviando il supporto si otterrà un menu, premendo il tasto enter il sistema
-partirà utilizzando la voce #{Live}# e le opzioni predefinite. Per ulteriori
-informazioni sulle opzioni di boot, si veda la voce "help" nel menu e le
-pagine di manuale di #{live-boot}# e #{live-config}# all'interno del
-sistema.
-
-Supponendo di aver selezionato #{Live}# e avviato l'immagine desktop
-predefinita, dopo i messaggi di avvio si dovrebbe automaticamente accedere
-all'account #{user}# e avere il desktop pronto all'uso. Se invece si è
-avviata un'immagine per la sola console, come le preconfezionate
-#{standard}# o #{rescue}#, si accederà alla console dell'account #{user}# ed
-avere un prompt di shell pronto da usare.
-
-2~using-virtual-machine Utilizzare una macchina virtuale per le prove
-
-Per lo sviluppo delle immagini live, può essere un notevole risparmio di
-tempo eseguirle in una macchina virtuale (VM). Non senza qualche
-raccomandazione:
-
-_* Eseguire una VM richiede un quantitativo sufficiente di RAM sia per il
-sistema ospitato che per quello ospitante; è consigliato un processore che
-gestisca la virtualizzazione a livello hardware.
-
-_* Ci sono alcune limitazioni inerenti, quali uno scarso rendimento video e
-una scelta limitata di hardware emulato.
-
-_* Quando si sviluppa per un hardware specifico non vi è alcun sostituto
-migliore del proprio hardware.
-
-_* Occasionalmente possono esserci dei bug relativi al solo utilizzo di una
-VM. Nel dubbio si provi l'immagine direttamente sul proprio hardware.
-
-A condizione che si possa lavorare entro questi vincoli, cercare il software
-disponibile per la virtualizzazione e scegliere quello adatto alle proprie
-necessità.
-
-3~testing-iso-with-qemu Provare un'immagine ISO con QEMU
-
-Il programma più versatile in Debian è QEMU. Se il processore gestisce la
-virtualizzazione hardware utilizzare il pacchetto #{qemu-kvm}#; la
-descrizione elenca brevemente i requisiti.
-
-Per prima cosa installare #{qemu-kvm}# o altrimenti #{qemu}#, nel qual caso
-il nome del programma nei successivi sarà #{qemu}# invece di #{kvm}#. Il
-pacchetto #{qemu-utils}# è inoltre utile per creare immagini di dischi
-virtuali con #{qemu-img}#.
-
-code{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Avviare un'immagine ISO è semplice:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-Per maggiori dettagli si vedano le pagine di manuale.
-
-3~testing-iso-with-virtualbox Provare un'immagine ISO con virtualbox-ose
-
-Per provare la ISO con #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Creare una nuova macchina virtuale, modificare le impostazione di
-archiviazione in modo da usare #{binary-hybrid.iso}# come dispositivo
-CD/DVD, e avviare la macchina.
-
-Nota: per sistemi live contenenti X.org che si vogliono provare con
-#{virtualbox-ose}#, si può voler includere il pacchetto dei driver per X.org
-di VirtualBox, #{virtualbox-ose-guest-x11}#, nella configurazione di
-live-build. In caso contrario la risoluzione è limitata a 800x600.
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Creare un'immagine USB/HDD
-
-La creazione di un'immagine USB/HDD è simile alla ISO ibrida sotto tutti gli
-aspetti ad eccezione della necessità di specificare l'opzione #{-b usb-hdd}#
-e che il nome del file risultante è #{binary.img}# e non può essere
-masterizzato. È adatta per avviarsi da chiavette USB, dischi rigidi USB, e
-da svariati altri dispositivi di archiviazione portatili. In genere per
-questo scopo può essere usata un'immagine ISO ibrida, ma se si ha un BIOS
-che non supporta le immagini ibride, o si vuole usare lo spazio rimanente
-sul supporto per altri scopi, come una partizione persistente, allora
-occorre un'immagine USB/HDD.
-
-Nota: se si è creata un'immagine ISO ibrida con gli esempi precedenti,
-occorre pulire la directory di lavoro con il comando #{lb clean}# (vedere
-{Il comando lb clean}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Eseguire il comando #{lb config}# come prima, questa volta specificando però
-il tipo di immagine USB/HDD:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Si crei ora l'immagine con il comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-Quando la costruzione è terminata dovrebbe essere presente un file
-#{binary.img}# nella directory corrente.
-
-2~using-usb-hdd-image Utilizzare un'immagine USB/HDD
-
-L'immagine binaria generata contiene una partizione VFAT e il bootloader
-syslinux, pronti per essere scritti direttamente su una penna USB. Dal
-momento che utilizzare un'immagine USB/HDD è come utilizzare un'immagine ISO
-ibrida via USB, seguire le istruzioni contenute in {Utilizzare un'immagine
-live ISO ibrida}#using-iso-hybrid tenendo però conto che il nome del file
-sarà #{binary.img}# invece di #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Provare un'immagine USB/HDD con Qemu
-
-Installare QEMU come descritto in {Provare un'immagine ISO con
-QEMU}#testing-iso-with-qemu; quindi eseguire #{kvm}# o #{qemu}#, a seconda
-di quale versione è necessaria al sistema ospitante, specificando
-#{binary.img}# come disco rigido principale.
-
-code{
-
- $ kvm -hda binary.img
-
-}code
-
-3~using-usb-extra-space Usare lo spazio rimanente su una penna USB
-
-Per utilizzare lo spazio libero che rimane dopo aver copiato il file
-#{binary.img}# su una penna USB, usare uno strumento di partizionamento come
-#{gparted}# o #{parted}# per creare una nuova partizione. La prima
-partizione verrà utilizzata dal sistema Debian Live.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-Dopo aver creato la partizione, dove #{${PARTITION}}# è il nome della
-partizione, ad esempio #{/dev/sdb2}#, si deve creare su di essa un
-filesystem. Una scelta possibile potrebbe essere ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Nota: se si desidera utilizzare lo spazio extra con Windows pare che questo
-sistema operativo non possa accedere a nessuna partizione eccetto la
-prima. Alcune soluzioni a questo problema sono state discusse sulla nostra
-{mailing list}#contact, ma non sembrano esserci risposte semplici.
-
-*{Ricorda: ogni volta che si installa un nuovo file binary.img sulla penna, tutti i dati sulla chiavetta saranno persi perché la tabella delle partizioni viene sovrascritta con i contenuti dell'immagine, per cui salvare prima la propria partizione extra in modo da ripristinarla dopo l'aggiornamento dell'immagine live.}*
-
-2~building-netboot-image Creare un'immagine netboot
-
-La seguente sequenza di comandi creerà un'immagine netboot di base
-contenente il sistema Debian standard senza X.org. È adatta per il boot
-tramite rete.
-
-Nota: se qualcuno tra gli esempi precedenti è stato seguito, bisogna pulire
-la directory di lavoro con il comando #{lb clean}#:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Per configurare l'immagine per l'avvio da rete, eseguire il comando #{lb
-config}# come segue:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-Diversamente dalle immagini ISO e USB/HDD, il boot via rete non fornisce
-un'immagine del filesytem al client, perciò i file devono essere forniti via
-NFS. Le opzioni net-root-path e net-root-server specificano,
-rispettivamente, il percorso e il server del server NFS dove l'immagine del
-filesystem sarà situata all'avvio. Accertarsi che questi siano impostati su
-valori adeguati alla propria rete.
-
-Si crei ora l'immagine con il comando #{lb build}#:
-
-code{
-
- # lb build
-
-}code
-
-In un avvio tramite rete, il client esegue una piccola parte di software che
-normalmente risiede sulla EPROM della scheda Ethernet. Questo programma
-invia una richiesta DHCP per ottenere un indirizzo IP e le informazioni su
-cosa fare in seguito. In genere il passo successivo è ottenere un bootloader
-di di livello superiore attraverso il protocollo TFTP. Questi potrebbe
-essere pxelinux, GRUB, o anche avviare direttamente un sistema operativo
-come Linux.
-
-Per esempio, estraendo l'archivio generato #{binary-net.tar.gz}# nella
-directory #{/srv/debian-live}#, si troverà l'immagine del filesystem in
-#{live/filesystem.squashfs}# mentre il kernel, initrd ed il bootloader
-pxelinux in #{tftpboot/debian-live/i386}#.
-
-Per abilitare l'avvio tramite rete vanno ora configurati tre servizi:i
-server DHCP, TFTP e NFS.
-
-3~ Server DHCP
-
-Si deve configurare il server DHCP della rete per essere sicuri di fornire
-un indirizzo IP al sistema client che si avvia tramite rete, e notificare la
-posizione del bootloader PXE.
-
-Ecco un esempio, scritto per un server DHCP ISC #{isc-dhcp-server}# nel file
-di configurazione #{/etc/dhcp/dhcpd.conf}#:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ Server TFTP
-
-Fornisce al sistema il kernel e il ramdisk iniziale in fase di esecuzione.
-
-Si installi il pacchetto tftpd-hpa, che mette a disposizione tutti i file
-contenuti in una directory root, di solito #{/srv/tftp}#. Affinché si possa
-disporre dei file contenuti in #{/srv/debian-live/tftpboot}#, eseguire il
-seguente comando come utente root:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-e inserire la nuova directory del server tftp quando viene richiesto.
-
-3~ Server NFS
-
-Una volta che il computer ospite ha scaricato e avviato un kernel Linux e
-caricato il suo initrd, cercherà di montare l'immagine del filesystem Live
-tramite un server NFS.
-
-Bisogna installare il pacchetto #{nfs-kernel-server}#.
-
-Quindi, rendere disponibile l'immagine del filesystem via NFS aggiungendo
-una riga come la seguente in #{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-e comunicare il nuovo export al server NFS con il seguente comando:
-
-code{
-
- # exportfs -rv
-
-}code
-
-Configurare questi tre servizi può essere un po' problematico. Serve un po'
-di pazienza per farli funzionare assieme. Per ulteriori informazioni, si
-veda il wiki syslinux http://syslinux.zytor.com/wiki/index.php/PXELINUX o il
-manuale del Debian Installer alla sezione per l'avvio TFTP da rete
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. Ciò può essere
-d'aiuto, considerato che il procedimento è molto simile.
-
-3~ Come provare una netboot
-
-La creazione di immagini netboot è resa semplice dal potere di live-build,
-ma provare le immagini su una macchina reale può essere davvero dispendioso
-in termini di tempo.
-
-Per semplificarsi la vita, si può usare la virtualizzazione. Ci sono due
-soluzioni.
-
-3~ Qemu
-
-_* Installare #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Modificare #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Procurarsi o compilare #{grub-floppy-netboot}# (su svn).
-
-Lanciare #{qemu}# con "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Installare VMWare Player (edizione "free as in beer")
-
-_* Creare una directory PXETester, e crearvi all'interno un file di testo
-chiamato #{pxe.vwx}#
-
-_* Vi si copi dentro questo testo:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* Si può modificare a piacimento questo file di configurazione (ad esempio
-portando a 256 il limite della memoria)
-
-_* Fare doppio click su questo file (o avviare il player VMWare e
-selezionare questo file).
-
-_* Se viene posta qualche strana domanda durante l'esecuzione premere il
-tasto spazio...
diff --git a/manual/it/user_customization-binary.ssi b/manual/it/user_customization-binary.ssi
deleted file mode 100644
index ed0aa19..0000000
--- a/manual/it/user_customization-binary.ssi
+++ /dev/null
@@ -1,38 +0,0 @@
-B~ Personalizzare l'immagine binaria
-
-1~customizing-binary Personalizzare l'immagine binaria
-
-2~ Bootloader
-
-live-build usa syslinux come bootloader predefinito, il quale è configurato
-per restare in pausa continua sulla schermata d'avvio. Per cambiare questo
-comportamento, si passi #{--syslinux-timeout TIMEOUT}# a #{lb
-config}#. Questo valore è espresso in secondi, 0 (zero) disabilita
-completamente il tempo di attesa. Per maggiori informazioni vedere
-syslinux(1).
-
-2~ Metadati ISO
-
-Quando si crea un'immagine binaria ISO9660, si possono usare le seguenti
-opzioni per aggiungere vari metadati testuali. Questo può aiutare a
-identificare facilmente la versione o la configurazione di un'immagine senza
-avviarla.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: descrive l'applicazione
-che sarà nell'immagine. La lunghezza massima per questo campo è di 128
-caratteri.
-
-* #{LB_ISO_PREPARER/--iso-preparer NAME}#: descrive il costruttore
-dell'mmagine, solitamente con alcuni dettagli per
-contattarlo. L'impostazione predefinita è la versione di live-build che si
-sta usando, il quale potrà essere utile in seguito per il debugging. La
-lunghezza massima per questo campo è di 128 caratteri.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: descrive l'editore
-dell'immagine, solitamente con qualche dettaglio per contattarlo. La
-lunghezza massima lunghezza per questo campo è di 128 caratteri.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: specifica l'ID del volume
-dell'immagine. Questa è utilizzata come etichetta visibile all'utente su
-alcune piattaforme, come Windows e Apple Mac OS. La lunghezza massima per
-questo campo è di 128 caratteri.
diff --git a/manual/it/user_customization-contents.ssi b/manual/it/user_customization-contents.ssi
deleted file mode 100644
index f1a1ce6..0000000
--- a/manual/it/user_customization-contents.ssi
+++ /dev/null
@@ -1,157 +0,0 @@
-B~ Personalizzazione dei contenuti
-
-1~customizing-contents Personalizzazione dei contenuti
-
-Questo capitolo tratta la personalizzazione dei contenuti del sistema live
-che va oltre la semplice scelta dei pacchetti da includere. Gli include
-permettono di aggiungere o sostituire file nell'immagine di Debian Live, gli
-hook permettono di eseguire comandi in fasi differenti della creazione e
-all'avvio, e la preconfigurazione permette di configurare i pacchetti quando
-vengono installati fornendo risposte alle domande di debconf.
-
-2~ Include
-
-Anche se idealmente un sistema live Debian dovrebbe includere file forniti
-interamente dal pacchetti Debian non modificati, a volte è conveniente
-fornire o modificare parte del contenuto per mezzo di file. Utilizzando gli
-include, si può aggiungere (o sostituire) file arbitrari nell'immagine di
-Debian Live. Per usarli, live-build mette a disposizione tre meccanismi:
-
-_* Include locali del chroot: permettono di aggiungere o sostituire file al
-file system chroot/Live. Vedere {Live/chroot include
-locali}#live-chroot-local-includes per maggiori informazioni.
-
-_* Include locali binari: permettono di aggiungere o sostituire file
-nell'immagine binaria. Vedere {Include locali binari}#binary-local-includes
-per maggiori informazioni
-
-_* Include binari: permettono di aggiungere o sostituire specifici file
-Debian nell'immagine binaria, come le directory dei template e dei
-tool. Vedere {Include binari}#binary-includes per maggiori informazioni.
-
-Si consulti il {Glossario}#terms per ulteriori informazioni sulla
-distinzione tra immagini "Live" e "binarie".
-
-3~live-chroot-local-includes Live/chroot include locali
-
-Gli include locali del chroot possono essere usati per aggiungere o
-sostituire file nel filesystem chroot/Live in modo che possano essere
-utilizzati nel sistema live. Un utilizzo tipico è popolare la directory
-scheletro dell'utente (#{/etc/skel}#) che il sistema impiega per creare la
-home dell'utente. Un altro è quello di fornire file di configurazione che
-possono essere semplicemente aggiunti o sostituiti nell'immagine senza
-elaborazione; si veda {Live/chroot hook locali}#live-chroot-local-hooks se è
-necessaria l'elaborazione.
-
-Per includere i file si aggiungano semplicemente alla directory
-#{config/chroot_local-includes}#. Questa corrisponde alla directory root
-(#{/}#) del sistema live. Per esempio, per aggiungere un file
-#{/var/www/index.html}# nel sistema live, si usi:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/var/www
- $ cp /path/to/my/index.html config/chroot_local-includes/var/www
-
-}code
-
-La configurazione avrà quindi il seguente schema:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Gli include locali del chroot vengono installati dopo l'installazione dei
-pacchetti in modo che tali file vengano in seguito sovrascitti.
-
-3~binary-local-includes Include locali binari
-
-Si possono utilizzare include locali binari per inserire sul filesystem del
-supporto materiale come documentazione o video affinché sia immediatamente
-accessibile dopo l'inserimento dello stesso senza avviare il sistema
-live. Ciò funziona in modo simile agli include locali del chroot; supponendo
-che i file #{~/video_demo.*}# siano video dimostrativi del sistema descritti
-da e collegati a una pagina HTML indice, basta copiare il materiale in
-#{config/binary_local-includes/}# come segue:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-Questi file appariranno nella directory principale del supporto live.
-
-3~binary-includes Include binari
-
-live-build ha alcuni file standard (come la documentazione) inclusi nella
-configurazione predefinita di ogni supporto live. Ciò può essere
-disabilitato con:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-In caso contrario il materiale verrà installato da live-build nella
-directory #{/includes/}# del filesystem in modo predefinito, oppure è
-possibile specificare un percorso alternativo con #{--includes}#.
-
-2~ Hook
-
-Gli hook permettono di eseguire comandi nel chroot e nelle fasi binarie
-della creazione al fine di personalizzare l'immagine.
-
-3~live-chroot-local-hooks Live/chroot hook locali
-
-Per eseguire comandi nella fase chroot, creare uno script hook contenente i
-comandi nella directory #{config/chroot_local-hooks}#. L'hook verrà eseguito
-nel chroot dopo che verrà applicata il resto della configurazione del
-chroot, ricordare quindi di garantire che la propria configurazione includa
-tutti i pacchetti e i file che l'hook necessita per funzionare. Vedere gli
-script d'esempio degli hook di chroot per i vari compiti di
-personalizzazione del chroot contenuti in
-#{/usr/share/live/build/examples/hooks}# da copiare o collegare nella
-propria configurazione.
-
-3~boot-time-hooks Hook in fase di avvio
-
-Per eseguire comandi all'avvio, è possibile fornire degli hook a live-config
-come spiegato nella sezione "Customization" del suo manuale. Controllare gli
-hook di live-config in #{/lib/live/config/}# e notare i numeri sequenziali;
-fornire quindi i propri hook con una sequenza numerica appropriata, sia come
-include locali del chroot in
-#{config/chroot_local-includes/lib/live/config/}#, sia come pacchetto
-personalizzato come discusso in {Installare pacchetti modificati o di terze
-parti}#installing-modified-or-third-party-packages.
-
-3~ Hook binari locali
-
-Per eseguire comandi nella fase binaria, creare uno script hook che contenga
-i comandi in #{config/binary_local-hooks}#. L'hook verrà eseguito dopo tutti
-gli altri comandi binari, ma prima del binary_checksums, l'ultimo definitivo
-comando. I comandi nel proprio hook non vengono eseguiti nel chroot, perciò
-si faccia attenzione a non modificare nessun file al di fuori dell'albero di
-costruzione o si danneggerà il sistema! Vedere gli script d'esempio per gli
-hook binari per i vari compiti di personalizzazione dei binari in
-#{/usr/share/live/build/examples/hooks}# da copiare o collegare nella
-propria configurazione.
-
-2~ Preconfigurare le domande di Debconf
-
-I file nella directory #{config/chroot_local-preseed}# sono considerati file
-di preconfigurazione di debconf e sono installati da live-build usando
-#{debconf-set-selections}#.
-
-Per ulteriori informazioni su debconf, vedere debconf(7) nel pacchetto
-#{debconf}#.
diff --git a/manual/it/user_customization-installer.ssi b/manual/it/user_customization-installer.ssi
deleted file mode 100644
index 1b1e907..0000000
--- a/manual/it/user_customization-installer.ssi
+++ /dev/null
@@ -1,89 +0,0 @@
-:B~ Personalizzare il Debian Installer
-
-1~customizing-installer Personalizzare il Debian Installer
-
-Le immagini del sistema Debian Live possono essere integrate nel Debian
-Installer. Ci sono differenti tipi d'installazione che variano in cosa viene
-incluso e come agisce l'installatore.
-
-In questa sezione si presti attenzione all'uso delle lettere maiuscole
-quando si fa riferimento al "Debian Installer" - quando usato ci si
-riferisce all'installatore ufficiale Debian, niente altro. Spesso è
-abbreviato come "d-i".
-
-2~ Tipologie del Debian Installer
-
-I tre principali tipi dell'installer sono:
-
-*{Debian Installer "normale"}*: questa è un'immagine Debian Live con un kernel e un initrd separati i quali (quando viene selezionato da un appropriato bootloader) lancia un'istanza standard del Debian Installer, così come quando si scarica un'immagine di Debian e la si avvia. Le immagini che contengono un sistema live e un installatore indipendenti sono spesso definite "immagini combinate".
-
-In queste immagini, Debian è installata prendendo e installando pacchetti
-.deb usando {debootstrap}# o #{cdebootstrap}# da supporti locali o dalla
-rete, risultante in un sistema Debian standard che viene installato sul
-disco rigido.
-
-L'intero processo può essere preimpostato e personalizzato in diversi modi;
-per ulteriori informazioni si vedano le corrispondenti pagine del manuale
-del Debian Installer. Una volta che si ha un file preimpostato che funzioni,
-live-build può inserirlo automaticamente nell'immagine e abilitarlo.
-
-*{Debian Installer "live"}*: Questa è un'immagine Debian Live con un kernel ed un initrd separato (quando selezionato dall'appropriato bootloader) lanciata in un'instanza del Debian Installer.
-
-L'installazione procederà nello stesso modo di un'installazione "Regolare"
-come descritto sopra, ma allo stadio attuale dell'installazione del
-pacchetto, invece di usare #{debootstrap}# per prelevare e installare i
-pacchetti, l'immagine del filesystem live viene copiata sulla
-destinazione. Questo si ottiene con uno speciale udeb chiamato
-live-installer.
-
-Dopo questa fase, il Debian Installer continua normalmente, installando e
-configurando elementi come bootloader e utenti locali, ecc.
-
-Si noti: per supportare entrambi le voci dell'installer live o normale nel
-bootloader sullo stesso media, si deve disabilitare il live-installer dalla
-preconfigurazione #{live-installer/enable=false}#.
-
-*{Debian Installer "Desktop"}*: indipendentemente dal tipo del Debian Installer incluso, #{d-i}# può essere lanciato cliccando un'icona sul desktop, Questo è molto semplice in alcune situazioni. Per poterne usufruire deve essere incluso il pacchetto debian-installer-launcher.
-
-Si noti che live-build non include il Debian Installer nell'immagine in modo
-predefinito, bisogna che sia espressamente abilitato con #{lb
-config}#.Inoltre, affinché l'installatore "Desktop" funzioni, il kernel del
-sistema live deve corrispondere a quello usato dal #{d-i}# per
-l'architettura specificata. Per esempio:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Personalizzare il Debian Installer con la preconfigurazione
-
-Come descritto nell'appendice B del manuale del Debian Installer
-all'indirizzo http://www.debian.org/releases/stable/i386/apb.html, "La
-preconfigurazione fornisce un modo per impostare le risposte alle domande
-poste durante il processo d'installazione senza la necessità di inserirle
-manualmente. Ciò permette di automatizzare totalmente molti tipi di
-installazione offrendo anche alcune caratteristiche normalmente non
-disponibili." Questo tipo di personalizzazione è compiuta in modo ottimale
-con live-build mettendo la configurazione in un file #{preseed.cfg}# incluso
-in #{config/binary_debian-installer/}#. Ad esempio per preconfigurare
-l'impostazione della localizzazione su #{en_US}#:
-
-code{
-
- $ echo "d-i debian-installer/locale string en_US" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Personalizzare il contenuto del Debian Installer
-
-Si può voler includere pacchetti udeb compilati localmente come componenti
-del #{d-i}# per scopi di sperimentazione o debug; per includerli
-nell'immagine inserirli in #{config/binary_local-udebs/}#. I file e le
-directory aggiuntivi o di rimpiazzo si possono includere nell'initrd
-dell'installatore in maniera simile agli {Include locali del
-Live/chroot}#live-chroot-local-includes, inserendo il materiale in
-#{config/binary_debian-installer-includes/}#.
diff --git a/manual/it/user_customization-overview.ssi b/manual/it/user_customization-overview.ssi
deleted file mode 100644
index 95bc061..0000000
--- a/manual/it/user_customization-overview.ssi
+++ /dev/null
@@ -1,79 +0,0 @@
-B~ Personalizzazione dei contenuti
-
-1~customization-overview Panoramica sulla personalizzazione
-
-Questo capitolo mostra una panoramica dei vari metodi con i quali è
-possibile personalizzare un sistema Debian Live.
-
-2~ Configurazione in fase di compilazione e di avvio
-
-La configurazione del sistema live è divisa in opzioni applicate in fase di
-compilazione e al momento dell'avvio. Le opzioni di compilazione sono
-ulteriormente divise in quelle che si verificano prima dell'avvio, applicate
-dal pacchetto live-boot, e quelle dopo l'avvio, applicate da
-live-config. Qualsiasi opzione in fase di avvio può essere modificata
-dall'utente specificandola al prompt di avvio. L'immagine può inoltre essere
-costruita con i parametri di avvio predefiniti in modo che quando tutti i
-valori predefiniti sono adatti gli utenti possano avviare direttamente il
-sistema senza specificare alcuna opzione. In particolare, l'argomento di
-#{lb --bootappend-live}# è costituito da tutte le opzioni da riga di comando
-del kernel predefinite in un sistema live, come persistenza dei dati, layout
-di tastiera o fuso orario. Per gli esempi si veda {Personalizzare
-localizzazione e lingua}#customizing-locale-and-language.
-
-Le opzioni di configurazione in fase di compilazione sono descritte nel
-manuale di #{lb config}#, mentre quelle in fase di avvio nel manuale di
-live-boot e live-config. Sebbene i pacchetti live-boot e live-config siano
-installati nel sistema live che si sta costruendo si raccomanda, per un
-comodo riferimento quando si lavora alla propria configurazione, di
-installarli anche sul sistema che lo crea. Fare ciò risulta sicuro in quanto
-nessuno degli script contenuti viene eseguito, a meno che il sistema sia
-configurato come sistema live.
-
-2~stages-of-the-build Fasi della creazione
-
-Il processo di creazione è diviso in due fasi, con varie personalizzazioni
-applicate in sequenza a ciascuna di esse. La prima consiste nell'*{avvio}*,
-questa è la fase iniziale di popolamento della directory di chroot con i
-pacchetti atti a creare un sistema Debian di base. Viene quindi seguita
-dalla fase *{chroot}* che completa la costruzione della directory chroot e
-la popola con tutti i pacchetti elencati nella configurazione insieme a
-qualsiasi altro materiale; la maggior parte della personalizzazione dei
-contenuti avviene in questa tappa. La parte finale della preparazione
-dell'immagine è la fase *{binaria}* che genera un'immagine avviabile
-utilizzando i contenuti della directory chroot per costruire il file system
-pricipale per il sistema live, includere l'installatore e ogni altro
-materiale aggiuntivo sul supporto di destinazione al di fuori del file
-system del sistema live. Una volta che l'immagine è pronta viene creato, se
-abilitato, l'archivio dei sorgenti nella fase *{sorgenti}*.
-
-All'interno di ciascuna di queste fasi c'è una sequenza particolare in cui
-vengono applicati i comandi, sono organizzati in modo da assicurare che le
-personalizzazioni siano ragionevolmente stratificate. Ad esempio, nella fase
-*{chroot}* i preseed vengono applicati prima che qualsiasi pacchetto sia
-installato, i pacchetti vengono installati prima di qualsiasi file incluso
-localmente o le patch sono applicate e gli hook eseguiti dopo che tutto il
-materiale è a posto.
-
-2~ Integrare la configurazione di lb con dei file
-
-Anche se #{lb config}# crea una configurazione scheletrica nella directory
-config/, per realizzare i propri obiettivi potrebbe essere necessario
-fornire dei file aggiuntivi nelle sottodirectory. A seconda di dove vengono
-memorizzati i file nella configurazione, possono essere copiati nel file
-system del sistema live o nel file system dell'immagine binaria, o fornire
-configurazioni per la creazione del sistema che sarebbe scomodo passare come
-opzioni da riga di comando. Si possono includere cose come elenchi
-personalizzati dei pacchetti, grafica personalizzata o script hook da
-eseguire sia al momento della compilazione che in fase di avvio;
-incrementando quindi la notevole flessibilità di debian-live con il proprio
-codice.
-
-2~ Personalizzazione dei compiti
-
-I capitoli seguenti sono costituiti dai tipi di compito personalizzato che
-gli utenti eseguono solitamente: {personalizzare l'installazione dei
-pacchetti}#customizing-package-installation, {personalizzare i
-contenuti}#customizing-contents e {personalizzare localizzazione e
-lingua}#customizing-locale-and-language coprono solo alcune delle cose che
-si potrebbero desiderare.
diff --git a/manual/it/user_customization-packages.ssi b/manual/it/user_customization-packages.ssi
deleted file mode 100644
index 1fab27b..0000000
--- a/manual/it/user_customization-packages.ssi
+++ /dev/null
@@ -1,601 +0,0 @@
-:B~ Personalizzare l'installazione dei pacchetti
-
-1~customizing-package-installation Personalizzare l'installazione dei
-pacchetti
-
-Probabilmente la personalizzazione basilare di un sistema Debian Live è la
-scelta dei pacchetti da includere nell'immagine. Questo capitolo vi guiderà
-tra le varie opzioni in fase di costruzione per personalizzare
-l'installazione dei pacchetti di live-build. Le ampie scelte che influenzano
-quali pacchetti siano disponibili da installare nell'immagine sono le aree
-di distribuzione e archivio. Per essere sicuri di avere una ragionevole
-velocità di scaricamento, dovreste usare un mirror a voi vicino. Si possono
-inoltre aggiungere i propri repository per pacchetti di backport,
-sperimentali o personalizzati, o aggiungere i pacchetti direttamente come
-file. È possibile definire una propria lista di pacchetti da includere,
-usarne una predefinita di live-build, usare task di #{tasksel}#, o una
-combinazione di tutti e tre. Infine una serie di opzioni fornisce un certo
-controllo su apt, o aptitude se si preferisce, in fase di compilazione
-quando i pacchetti sono installati. Ciò può tornare utile se si usa un
-proxy, se si vuole disabilitare l'installazione dei pacchetti raccomandati
-per risparmiare spazio o controllare quali versioni dei pacchetti vengono
-installate con il pinning, giusto per citare alcune possibilità.
-
-2~ Sorgenti dei pacchetti
-
-3~ Distribuzione, le aree di archivio e le modalità
-
-La distribuzione che viene scelta ha un ampio impatto su quali pacchetti
-siano disponibili per essere inclusi nell'immagine live. Specificare il nome
-in codice, il predefinito per la versione Squeeze di live-build è
-#{squeeze}#; qualsiasi attuale distribuzione mantenuta negli archivi Debian
-può essere qui specificata con il suo nome in codice. (Per ulteriori
-dettagli consultare il {Glossario}#terms). L'opzione #{--distribution}# non
-solo influenza la sorgente dei pacchetti nell'archivio, ma indica a
-#{live-build}# di comportarsi secondo la necessità per compilare ciascuna
-distribuzione supportata. Ad esempio se si vuole costruire un rilascio
-*unstable*, Sid, specificare:
-
-code{
-
- $ lb config --distribution sid
-
-}code
-
-All'interno dell'archivio dei pacchetti, le aree sono le principali
-divisioni dello stesso. In Debian queste sono #{main}#, #{contrib}# e
-#{non-free}#; soltanto #{main}# contiene il software che è parte di Debian,
-perciò questa è la predefinita. Possono essere specificati uno o più valori:
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Attraverso l'opzione #{--mode}# è disponibile un supporto sperimentale per
-alcune derivate di Debian; per impostazione predefinita, questa opzione è
-impostata su #{debian}#, anche se si sta costruendo un sistema diverso da
-Debian. Se si specifica #{--mode ubuntu}# o #{--mode emdebian}#, saranno
-gestiti i nomi della distribuzione e le aree di archivio per la derivata
-specificata e non quelli di Debian. La modalità cambia anche il
-comportamento di live-build per adattarlo alle derivate.
-
-*{Nota:}* i progetti per i quali sono state aggiunte tali modalità sono i principali responsabili nel supportare gli utenti di queste opzioni. Il progetto Debian Live, a sua volta, fornisce sostegno allo sviluppo solamente sulla base dell'impegno migliore, sui feedback dei progetti derivati così come non sviluppiamo o sosteniamo queste derivate.
-
-3~ Mirror delle distribuzioni
-
-L'archivio Debian è replicato attraverso una vasta rete di mirror in tutto
-il mondo cosicché chiunque in ogni nazione può selezionare il mirror più
-vicino per la migliore velocità di scaricamento. Ciascuna delle opzioni
-#{--mirror-*}# determina quale mirror della distribuzione è usato nei vari
-stadi della compilazione. Ricordando dalle {Fasi della
-creazione}#stages-of-the-build che la fase di *avvio* è quando il chroot è
-inizialmente popolato da debootstrap con un sistema minimale e quella di
-*chroot* è quando viene creato il chroot usato per costruire il file system
-del sistema live. Perciò per queste fasi vengono usati i corrispondenti
-cambi di mirror, e in seguito, nella fase *binaria* vengono usati i valori
-di #{--mirror-binary}# e #{--mirror-binary-security}# sostituendo qualsiasi
-altro mirror usato nelle fasi iniziali.
-
-3~distribution-mirrors-build-time Mirror delle distribuzioni usati in fase
-di compilazione
-
-Per impostare i mirror delle distribuzioni usati in fase di compilazione ad
-uno locale, è sufficiente impostare #{--mirror-bootstrap}# e
-#{--mirror-chroot-security}# come segue.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-Il mirror chroot, specificato da #{--mirror-chroot}#, è impostato al valore
-di #{--mirror-bootstrap}#.
-
-3~ Mirror delle distribuzioni usate durante l'esecuzione
-
-Le opzioni #{--mirror-binary*}# determinano i mirror delle distribuzioni
-inseriti nell'immagine binaria. Questi possono essere usati per installare
-pacchetti aggiuntivi mentre il sistema live è in funzione. Le impostazioni
-predefinite impiegano #{cdn.debian.net}#, un servizio che sceglie un mirror
-geograficamente vicino basandosi sul numero IP dell'utente. Questo è una
-scelta conveniente quando non si può pronosticare quale sarà il mirror
-migliore per tutti gli utenti. Oppure si può specificare il proprio valore
-come mostrato nell'esempio qui sotto. Un'immagine compilata con questa
-configurazione sarebbe adatta solamente ad utenti di una rete dove sia
-raggiungibile il "#{mirror}#".
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Repository addizionali
-
-Si possono aggiungere altri repository, ampliando così la scelta dei
-pacchetti al di là di quelli disponibili nella distribuzione di
-destinazione. Questi possono essere, per esempio, pacchetti di backport,
-sperimentali o personalizzati. Per configurare repository aggiuntivi, creare
-i file #{config/chroot_sources/vostro-repository.chroot}#, o
-#{config/chroot_sources/vostro-repository.binary}#. Come per le opzioni
-#{--mirror-*}#, queste controlleranno i repository usati nella fase *chroot*
-quando si compila l'immagine, e nella fase *binary*, ad esempio per usarli
-quando il sistema live è avviato.
-
-Per esempio, #{config/chroot_sources/live.chroot}# permette di installare
-pacchetti dal repository snapshot di debian live al momento della creazione
-del sistema live.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-Se si aggiunge la stessa riga in #{config/chroot_sources/live.binary}#, il
-repository verrà aggiunto alla directory #{/etc/apt/sources.list.d/}# del
-sistema live.
-
-Se il file esiste, saranno prelevati automaticamente.
-
-Bisogna inoltre inserire la chiave GPG usata per firmare il repository nei
-file #{config/chroot_sources/vostro-repository.{binary,chroot}.gpg}#.
-
-*{Nota:}* alcuni repository di pacchetti preconfigurati sono disponibili per una facile selezione attraverso l'opzione #{--repository}#, per abilitare gli snapshot live è sufficiente un semplice comando:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Scegliere i pacchetti da installare
-
-Ci sono diversi modi per scegliere quali pacchetti live-build installerà
-nell'immagine, coprendo una gamma di esigenze diverse. Si possono scegliere
-i pacchetti singolarmente, con l'opzione #{--packages}# per un numero
-limitato, o da un elenco per una quantità maggiore di pacchetti. È inoltre
-possibile selezionare elenchi predefiniti più grandi o utilizzare i task di
-APT. E infine inserire i file dei pacchetti nell'albero #{config/}#, che ben
-si adatta alla alle prove di pacchetti nuovi o sperimentali prima che siano
-disponibili in un repository.
-
-3~ Scegliere pochi pacchetti
-
-Quando il numero dei pacchetti da aggiungere è esiguo è sufficiente
-specificare #{--packages}#. Per esempio:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-Quando si specifica un pacchetto che non esiste, il comportamento di
-live-build è determinato dalla scelta delle utilità di APT. Per ulteriori
-dettagli si veda {Scegliere apt o aptitude}#choosing-apt-or-aptitude.
-
-Se si necessita di specificare un gran numero di pacchetti o si desidera
-flessibilità su quali installare, usare gli elenchi dei pacchetti come
-discusso nella prossima sezione, {Elenchi di pacchetti}#package-lists.
-
-3~package-lists Elenchi di pacchetti
-
-Gli elenchi di pacchetti sono un potente mezzo per esprimere quali pacchetti
-devono essere installati. La sintassi gestisce file inclusi e sezioni
-condizionali rendendo semplice la creazione di elenchi da altri elenchi e
-adattarli per l'uso in molteplici configurazioni. Si può usare un elenco
-predefinito fornendo una selezione modulare dei pacchetti da ciascuno dei
-principali ambienti desktop e alcuni elenchi per uso speciale, così come
-elenchi standard sui quali vi si basano altri. È inoltre possibile fornire i
-propri elenchi o usare una combinazione di entrambi.
-
-3~ Elenchi predefiniti di pacchetti
-
-Il modo più semplice per usare gli elenchi è di specificarne uno o più con
-l'opzione #{--packages-lists}#. Per esempio:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-In aggiunta a questi elenchi, live-build ne gestisce quattro virtuali:
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#,
-ciascuno dei quali fornisce una selezione più estesa di pacchetti che
-corrisponde ai predefiniti dell'installatore Debian per ciascun ambiente
-desktop. Per ulteriori dettagli si veda {Task per desktop e
-lingua}#desktop-and-language-tasks.
-
-*{Nota:}* le immagini pre-costruite di GNOME, KDE, LXDE e XFCE disponibili per essere scaricate da http://live.debian.net sono costruite usando i corrispondenti elenchi #{*-desktop}# virtuali.
-
-Il percorso predefinito per i file elenco sul sistema è
-#{/usr/share/live/build/lists/}#. Per determinare i pacchetti in un dato
-elenco, si legga il file corrispondente, prestando attenzione ai file
-inclusi e condizionali come descritto nella sezioni seguenti.
-
-3~ Elenchi locali dei pacchetti
-
-Gli elenchi si possono integrare o sostituire interamente usando quelli
-locali dei pacchetti in #{config/chroot_local-packageslists/}#.
-
-Per essere processati, questi elenchi devono avere il suffisso #{.list}#. I
-locali sovrascrivono sempre quelli forniti con live-build, questo può
-causare effetti indesiderati perciò si raccomanda di usare nomi univoci.
-
-3~ Elenchi locali di pacchetti binari
-
-Nel caso in cui si desideri includere dei pacchetti .deb alla directory
-#{pool/}# della live (senza installarli sull'immagine) bisogna usare gli
-elenchi utilizzando quelli locali dei pacchetti binari situati in
-#{config/binary_local-packageslists/}#. Tale supporto può essere utilizzato
-come immagine personalizzata di Debian per installazioni non in linea.
-
-Per essere processate le liste dei pacchetti che si trovano nella directory
-deve avere un suffisso #{.list}#.
-
-3~ Estendere un'elenco di pacchetti usando gli include
-
-Gli elenchi di pacchetti inclusi in live-build fanno un notevole uso di
-include. Far riferimento a questi nella directory
-#{/usr/share/live/build/lists/}#, in quanto portano ottimi esempi su come
-scrivere i propri.
-
-Per esempio, per creare un elenco che includa quello predefinito di
-#{gnome}# più iceweasel, creare
-#{config/chroot_local-packageslists/mygnome.list}# con i seguenti contenuti:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Usare condizioni all'interno degli elenchi di pacchetti
-
-Ognuna delle variabili di configurazione di live-build situate in
-#{config/*}# (senza il prefisso #{LB_}#) possono essere utilizzate per
-istruzioni condizionali nell'elenco dei pacchetti. In genere questo
-significa qualsiasi opzione di #{lb config}# in maiuscolo e con trattini
-cambiati in trattini bassi; ma in pratica è la sola ad influenzare la
-selezione dei pacchetti che abbia senso, come #{DISTRIBUTION}#,
-#{ARCHITECTURE}# o #{ARCHIVE_AREAS}#.
-
-Per esempio, per installare #{ia32-libs}# se è specificata #{--architecture
-amd64}#:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-Si può verificare per ognuna di una serie di valori, ad esempio per
-installare #{memtest86+}# specificando sia #{--architecture i386}# sia
-#{--architecture amd64}#:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-È possibile provare altre variabili che contengano più di un valore, ad
-esempio per installare #{vrms}# specificando sia da #{contrib}# sia da
-#{non-free}# tramite #{--archive-areas}#:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-Una condizione può coinvolegere una direttiva #{#include}#:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-Le condizioni nidificate non sono supportate.
-
-3~ Task
-
-L'installatore Debian offre all'utente la scelta di vari elenchi di
-pacchetti pre-selezionati, ognuno dei quali focalizzato su un particolare
-tipo di sistema, o il tipo di attività per cui utilizzarlo, come "Graphical
-desktop environment", "Mail server" o "Laptop". Questi elenchi sono chiamati
-"task" e sono gestiti da APT atraverso il campo"Task:". In live-build si
-possono specificare uno o più task per mezzo dell'opzione #{--tasks}#, come
-nell'esempio seguente.
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-I task principali disponibili nell'installatore Debian possono essere
-elencati nel sistema live con #{tasksel --list-tasks}#. I contenuti di ogni
-task, inclusi quelli non inclusi in questo elenco, possono essere esaminati
-con #{tasksel --task-packages}#.
-
-3~desktop-and-language-tasks Task per desktop e lingua
-
-I task per i desktop e la lingua sono un caso speciale. Nell'installatore
-Debian, se il supporto è stato preparato per un particolare ambiente
-desktop, il corrispondente task verrà automaticamente installato. Perciò ci
-sono i task #{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# e
-#{xfce-desktop}#, nessuno dei quali è offerto nel menu di #{tasksel}#. Allo
-stesso modo, non c'è nessuna voce nel menu per i task delle lingue, ma la
-scelta della lingua dell'utente durante l'installazione influenza la
-selezione dei corrispondenti task della lingua.
-
-Perciò in live-build a questi casi particolari è anche data particolare
-considerazione, ma con tre differenze notevoli al momento in cui si scrive.
-
-Primo, non è stata fatta ancora alcuna previsione sui task della lingua,
-sebbene sia incluso un sottoinsieme di questi pacchetti specificando #{lb
-config --language}#. Se servono questi task, i quali includono cose come
-caratteri specifici per la lingua e pacchetti dei metodi di input, vanno
-specificati nella configurazione. Per esempio:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-Secondo, live-build gestisce gli elenchi #{*-desktop}# virtuali dei
-pacchetti per ogni tipo di desktop menzionato sopra, il quale seleziona
-l'elenco predefinito #{standard-x11}#, il corrispondente task #{*-desktop}#
-e tre task addizionali: #{desktop}#, #{standard}# e #{laptop}#. Così per
-esempio, se si specifica #{--packages-lists gnome-desktop}#, è l'equivalente
-di #{--packages debian-installer-launcher --packages-lists standard-x11
---tasks "gnome-desktop desktop standard laptop"}#.
-
-Terzo, se viene selezionato uno qualsiasi dei task per i vari desktop, sia
-esplicitamente con #{--tasks}# o implicitamente con #{--packages-lists}#,
-live-build pre-imposterà il corrispondente valore desktop per l'installatore
-Debian (se incluso) per garantire che segua le proprie regole per installare
-i vari tipi di desktop.
-
-*{Nota:}* esiste anche l'opzione sperimentale #{--language}# con lo scopo di sovrapporsi ai task della lingua. Se #{--language}# è specificato, per ogni lingua per la quale sia nota la presenza di pacchetti #{*-l10n}# questi verranno installati. Inoltre se uno dei modelli #{syslinux}# corrisponde alla lingua trovata, questi saranno usati al posto di quello inglese predefinito. La selezione dei pacchetti fatta con #{--language}# è un'approssimazione dei task della lingua, in quanto richiede che l'elenco dei pacchetti da includere per ogni lingua sia mantenuta all'interno di live-build, oltretutto i task della lingua sono più completi e flessibili; per quanto l'aspetto di #{syslinux}# sia comunque utile. Quindi utilizzando #{--bootloader syslinux}#, e se i modelli per la lingua specificata esistono in #{/usr/share/live/build/templates/syslinux/}# o in #{config/templates/syslinux/}#, si può considerare questa opzione, eventualmente in combinazione con i task per garantire c
he vengano installati tutti i pacchetti interessati. Esempio:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Anche così è limitato dal fatto che gestisce una sola lingua e un solo
-bootloader. Pertanto, per tutte queste ragioni, il futuro di questa opzione
-è in revisione, potrebbe essere sostituito con qualcosa di totalmente
-diverso nel prossimo rilascio di live-build.
-
-2~installing-modified-or-third-party-packages Installare pacchetti
-modificati o di terze parti
-
-Nonostante sia contro la filosofia di Debian Live, a volte può essere
-necessario creare un sistema live con versioni modificate dei pacchetti nel
-repository Debian. Questo per modificare o gestire funzionalità aggiuntive,
-lingue e marchi, o anche rimuovere elementi non desiderati da pacchetti
-esistenti. Allo stesso modo, i pacchetti di "terze parti" possono essere
-utilizzati per aggiungere funzionalità proprietarie o su misura.
-
-Questa sezione non tratta la compilazione e il mantenimento di pacchetti
-modificati. Può comunque essere interessante leggere "How to fork privately"
-di Joachim Breitner:
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
-La creazione di pacchetti su misura è esposta nella "Guida per il nuovo
-Maintainer" all'indirizzo http://www.debian.org/doc/maint-guide/ e altrove.
-
-Ci sono due modi per installare pacchetti personalizzati:
-
-_* #{chroot_local-packages}#
-
-_* Utilizzare repository APT personalizzati
-
-Usando #{chroot_local-packages}# è più semplice da ottenere e utile per una
-personalizzazione "una tantum" ma ha una serie di svantaggi, mentre un
-repository APT personalizzato è più laborioso da configurare.
-
-3~ Utilizzare #{chroot_local-packages}# per installare pacchetti
-personalizzati
-
-Per installare un pacchetto personalizzato copiarlo nella directory
-#{config/chroot_local-packages/}#; i pacchetti al suo interno verranno
-installati automaticamente durante la creazione del sistema live, non è
-necessario specificarli altrove.
-
-I pacchetti *{devono}* essere nominati nel modo prescritto, un metodo
-semplice per farlo è usare #{dpkg-name}#.
-
-L'utilizzo di #{chroot_local-packages}# per l'installazione di pacchetti
-personalizzati presenta degli svantaggi:
-
-_* non è possibile usare secure APT
-
-_* è necessario installare i pacchetti adeguati nella directory
-#{config/chroot_local-packages/}#.
-
-_* non si presta a salvare le configurazioni di Debian Live nel controllo di
-versione.
-
-3~ Utilizzare un repository APT per installare pacchetti personalizzati
-
-A differenza di #{chroot_local-packages}#, quando si usa un repository APT
-personalizzato è necessario assicurarsi di specificare altrove i
-pacchetti. Per i dettagli si veda {Scegliere i pacchetti da
-installare}#choosing-packages-to-install.
-
-Sebbene creare un repository APT possa sembrare uno sforzo inutile,
-l'infrastruttura può facilmente essere riutilizzata in un secondo momento
-per offrire aggiornamenti dei pacchetti modificati.
-
-3~ Pacchetti personalizzati e APT
-
-live-build utilizza APT per installare tutti i pacchetti nel sistema live in
-modo da ereditare i comportamenti di questo programma. Un esempio rilevante
-è che (considerando una configurazione predefinita) dato un pacchetto
-disponibile in due repository differenti con numeri di versione diversi, APT
-sceglie di installare quello con il numero di versione più alto.
-
-A causa di questo si può voler incrementare il numero della versione nei
-file #{debian/changelog}# dei pacchetti personalizzati per accertare che la
-propria versione avrà la precedenza sui repository Debian ufficiali. È anche
-ottenibile modificando le preferenze del APT pinning del sistema live, si
-veda {APT pinning}#apt-pinning per maggiori informazioni.
-
-2~ Configurare APT in fase di costruzione
-
-APT è configurabile tramite una serie di opzioni applicate solo in fase di
-costruzione (la configurazione di APT utilizzata nel sistema live in
-esecuzione può essere configurata nel solito modo, ovvero includendo le
-impostazioni appropriate attraverso #{config/chroot_local_includes/}#). Per
-un elenco completo, cercare nel manuale di #{lb_config}# le opzioni che
-iniziano con #{apt}#.
-
-3~choosing-apt-or-aptitude Scegliere apt o aptitude
-
-Per installare pacchetti in fase di compilazione si può optare sia per
-#{apt}# sia per #{aptitude}#, l'argomento #{--apt}# di #{lb config}#
-determina quale usare. Sceglie il metodo implementando il comportamento
-preferito per l'installazione dei pacchetti, la notevole differenza è come
-vengono gestiti quelli mancanti.
-
-_* #{apt}#: se viene specificato un pacchetto mancante, l'installazione avrà
-esito negativo; questo è l'impostazine predefinita.
-
-_* #{aptitude}#: se viene specificato un pacchetto mancante, l'installazione
-avrà successo.
-
-3~ Utilizzare un proxy con APT
-
-Una configurazione di APT spesso richiesta è di amministrare la creazione di
-un'immagine dietro un proxy, lo si può specificare con le opzioni
-#{--apt-ftp-proxy}# o #{--apt-http-proxy}# secondo necessità:
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Modificare APT per risparmiare spazio
-
-Si può aver bisogno di risparmiare dello spazio sul supporto dell'immagine,
-in tal caso una o entrambe delle seguenti opzioni possono essere
-d'interesse.
-
-È possibile non includere gli indici di APT con:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-Questo non influenzerà le voci in /etc/apt/sources.list, determina solo se
-/var/lib/apt contiene o meno i file degli indici. Il compromesso è che APT
-necessita di quegli indici per operar enel sistema live, perciò prima di
-eseguire #{apt-cache search}# o #{apt-get install}#, per esempio, l'utente
-deve usare prima #{apt-get update}# per crearli.
-
-In caso si trovi che l'installazione dei pacchetti raccomandati appesantisca
-troppo l'immagine, si può disabilitare l'opzione predefinita di APT con:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-Qui il compromesso è dato dal fatto che se non si installano i raccomandati
-per un certo pacchetto, ovvero "pacchetti che si trovano assieme a questo
-eccetto in installazioni non usuali" (Debian Policy Manual, paragrafo 7.2),
-saranno omessi alcuni di quelli realmente necessari. Si suggerisce pertanto
-di verificare la differenza ottenuta nel proprio elenco di pacchetti
-disabilitando i raccomandati (vedere il file #{binary.packages}# generato da
-#{lb build}#) e includere nuovamente in esso quelli omessi che si desiderano
-installare. In alternativa, se si desidera lasciare un modesto numero di
-raccomandati, li si lasci abilitati e si assegni ad APT un pin di priorità
-negativo sui pacchetti selezionati affinché non vengano installati, come
-spiegato in {APT pinning}#apt-pinning.
-
-3~ Passare opzioni ad apt o aptitude
-
-Se non c'è un'opzione di #{lb config}# per modificare il comportamento di
-APT nel modo desiderato, si usi #{--apt-options}# o #{--aptitude-options}#
-per passare opzioni tramite il proprio strumento APT. Consultare il manuale
-di #{apt}# e #{aptitude}# per i dettagli.
-
-3~apt-pinning APT pinning
-
-Si prega di leggere prima il manuale di #{apt_preferences(5)}#. Il pinning
-può essere configurato sia in fase di costruzione sia di esecuzione; per la
-prima creare #{config/chroot_apt/preferences}#, per quest'ultima creare
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Nell'ipotesi di creare un sistema live Squeeze e avendo la necessità di
-installare da Sid tutti i pacchetti live destinati all'immagine binaria
-questa fase, bisogna aggiungere Sid alle fonti di APT e farne il pinning
-affinché verranno installati da lì solo i pacchetti voluti, mentre per tutti
-gli altri si attingerà dalla distribuzione principale, Squeeze. Quanto segue
-servirà allo scopo:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Nota:}* con la versione 0.8.14 o superiore di Apt si possono utilizzare wildcard nei nomi dei pacchetti (*{Package: live-*}*). Ciò significa che funziona con Wheezy usando:
-
-code{
-
-$ lb config --distribution wheezy
-
-}code
-
-Un valore negativo della priorità evita che un pacchetto venga installato,
-come nel caso in cui non se ne voglia uno raccomandato da un altro. Si
-suppone di costruire un'immagine di LXDE utilizzando l'opzione
-#{--packages-lists lxde}# ma non si desidera che all'utente venga richiesto
-di salvare la password del wifi nel portachiavi. L'elenco include #{gdm}#
-che dipende da #{gksu}# che a sua volta raccomanda #{gnome-keyring}#, in
-questo caso si vorrà omettere il pacchetto #{gnome-keyring}# aggiungendo a
-#{config/chroot_apt/preferences}# la seguente definizione:
-
-code{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/it/user_customization-runtime.ssi b/manual/it/user_customization-runtime.ssi
deleted file mode 100644
index 74095a0..0000000
--- a/manual/it/user_customization-runtime.ssi
+++ /dev/null
@@ -1,240 +0,0 @@
-:B~ Personalizzare i comportamenti durante l'esecuzione
-
-1~customizing-run-time-behaviours Personalizzare i comportamenti durante
-l'esecuzione
-
-Tutte le configurazioni durante l'esecuzione sono eseguite da
-live-config. Vengono qui presentate alcune delle opzioni di live-config più
-comuni alle quali gli utenti sono interessati; una lista completa può essere
-trovata nel suo manuale.
-
-2~ Personalizzare l'utente live
-
-Un'importante considerazione è che l'utente live viene creato all'avvio da
-live-boot e non da live-build durante la compilazione. Questo non solo
-influenza dove viene introdotto il materiale relativo all'utente nella
-creazione, come discusso in {Live/chroot include
-locali}#live-chroot-local-includes, ma anche ogni gruppo e permesso
-associato all'utente live.
-
-È possibile specificare gruppi aggiuntivi ai quali l'utente live apparterrà
-preconfigurando il valore #{passwd/user-default-groups}# di debconf. Ad
-esempio, per aggiungere l'utente al gruppo #{fuse}#, inserire quanto segue
-ad un file nella directory #{config/chroot_local-preseed}#:
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-It is also possible to change the default username "user" and the default
-password "live". If you want to do that for any reason, you can easily
-achieve it as follows:
-
-To change the default username you can simply specify it in your config:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-One possible way of changing the default password is by means of a hook as
-described in {Boot-time hooks}#boot-time-hooks. In order to do that you can
-use the "passwd" hook from #{/usr/share/doc/live-config/examples/hooks}#,
-prefix it accordingly (e.g. 200-passwd) and add it to
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Personalizzare la localizzazione e la
-lingua
-
-Quando il sistema live si avvia, la lingua è inserita in tre fasi:
-
-_* generazione della localizzazione
-
-_* impostazione del layout di tastiera per la console
-
-impostazione del layout di tastiera per X
-
-Quando si crea un sistema live la localizzazione predefinita è
-"locales=en_US.UTF-8". Per definire quale generare, si usi il parametro
-#{locales}# nell'opzione #{--bootappend-live}# di #{lb config}#:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-Questo parametro può inoltre essere usato dalla riga di comando del kernel,
-specificando una localizzazione nella forma #{lingua_nazione.codifica}#.
-
-Sia la configurazione della tastiera in console sia di X dipendono dal
-parametro #{keyboard-layouts}# dell'opzione #{--bootappend-live}#. Si
-possono trovare le opzioni valide per i layout di X in
-#{/usr/share/X11/xkb/rules/base.xml}# (piuttosto che limitate alle due
-lettere del codice della nazione); per trovare il valore (i due caratteri)
-corrispondenti alla lingua, si cerchi con il nome inglese della nazione in
-cui si parla tale lingua:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-Per ottenere i file di localizzazione per il layout di tastiera tedesco e
-svizzero-tedesco in X:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-Si può ottenere un elenco di valori validi della tastiera per la console con
-il seguente comando:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-In alternativa è possibile utilizzare il pacchetto #{console-setup}#, uno
-strumento per configurare il layout della console tramite le definizioni di
-X (XKB); si può dunque impostare il layout in modo più preciso con le
-variabili #{keyboard-layouts}#, #{keyboard-variant}#, #{keyboard-options}# e
-#{keyboard-model}#; live-boot userà questi parametri anche per X. Ad
-esempio, per impostare un layout French-Dvorak (chiamato Bepo) su un sistema
-francese con una tastiera TypeMatrix, sia in console sia in X11:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistenza
-
-Uno dei paradigmi di un cd live è un sistema preinstallato eseguito da un
-supporto in sola lettura, come un cdrom, dove le modifiche non sopravvivono
-ai riavvii dell'hardware della macchina ospitante.
-
-Un sistema Debian Live è una generalizzazione di questo paradigma e di
-conseguenza oltre ai CD gestisce altri supporti; ma comunque, nel suo
-comportamento predefinito, deve essere considerato in sola lettura e tutte i
-cambiamenti fatti durante l'esecuzione del sistema verranno persi allo
-spegnimento.
-
-Persistenza è il nome comune per differenti tipi di soluzioni per salvare
-alcune o tutte queste modifiche con i riavii. Per capire come funziona
-potrebbe essere utile sapere che sebbene il sistema venga avviato ed
-eseguito da un dispositivo in sola lettura, le modifiche a file e directory
-vengono scritte su uno scrivibile, tipicamente un ram disk (tmpfs) e i dati
-sui ram disk non sopravvivono ai riavvii.
-
-I dati immagazzinati su questo ramdisk andrebbero salvati un supporto
-scrivibile persistente come un hard disk, una chiave USB, una condivisione
-di rete o anche una sessione di un CD/DVD riscrivibile multisessione. Tutti
-questi supporti sono gestiti in Debian Live in modi differenti, e tutti
-tranne l'ultimo richiedono un parametro d'avvio speciale da specificare
-all'avvio: #{persistent}#.
-
-3~ Persistenza completa
-
-Con "persistenza completa" si intende l'uso di una partizione scrivibile
-invece di un filesystem temporaneo (tmpfs) per salvare le modifiche al
-supporto in sola lettura (con il sistema COW, copy-on-write). Per utilizzare
-questa caratteristica, una partizione con un filesystem scrivibile e
-supportato ed etichettata come "live-rw" deve essere collegata al sistema in
-fase di avvio e il sistema va fatto partire con il parametro
-"persistent". Questa partizione potrebbe essere di tipo ext2 su un hard disk
-o una penna usb creata ad esempio con:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-Si veda anche {Usare lo spazio rimanente su una penna
-USB}#using-usb-extra-space.
-
-Se si possiede già una partizione sul dispositivo basta solo cambiare
-l'etichetta con una delle seguenti:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-Ma siccome gli utenti dei sistemi live non hanno sempre la possibilità di
-utilizzare una partizione su disco rigido, e considerando che la maggior
-parte delle chiavi USB hanno scarse velocità di scrittura, la persistenza
-"completa" può anche essere usata con dei file immagine, è possibile creare
-un file che rappresenta una partizione e inserire questo file immagine anche
-su una partizione NTFS di un sistema operativo estraneo, qualcosa come:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-Quindi copiare il file #{live-rw}# su una partizione scrivibile e riavviare
-con il parametro d'avvio "persistent".
-
-3~ Mount automatico della home
-
-Se durante l'avvio viene trovata una partizione (filesystem) su file
-immagine o una partizione etichettata come #{home-rw}#, questa verrà montata
-direttamente come #{/home}#, permettendo quindi la persistenza dei file che
-appartengono ad esempio all'utente predefinito. Può essere unita alla
-persistenza completa.
-
-3~ Istantanee
-
-Le istantanee sono raccolte di file e directory che non vengono montate
-durante l'esecuzione ma copiate all'avvio da un dispositivo persistente al
-sistema (tmpfs) e risincronizzate al riavvio e spegnimento. Il contenuto di
-un'istantanea può risiedere su una partizione o file immagine (come i tipi
-menzionati poc'anzi) etichettati come #{live-sn}#, ma sotto forma di un
-semplice archivio cpio nominato #{live-sn.cpio.gz}#. Come sopra, all'avvio,
-i device a blocchi collegati al sistema vengono analizzati alla ricerca di
-una partizione o file così nominati. Un'interruzione di corrente durante
-l'esecuzione potrebbe portare ad una perdita di dati, per cui si può usare
-uno strumento che richiama #{live-snapshot --refresh}# per sincronizzare i
-cambiamenti importanti. Giacché non scrive continuamente sul dispositivo,
-questo tipo di persistenza è il sistema più comodo e veloce per dispositivi
-basati su memoria flash.
-
-Esiste anche un'istantanea della /home con etichetta #{home-sn.*}#; funziona
-come la principale ma viene applicata solo ad /home.
-
-Attualmente le istantanee non possono gestire la cancellazione dei file, al
-contrario della persistenza completa e il mount automatico della home.
-
-3~ Sottotesto persistente
-
-Se un utente avesse bisogno di archiviazioni multiple dello stesso tipo per
-differenti posti o per test, come #{live-rw-casa}# e #{live-rw-lavoro}#, il
-parametro d'avvio #{persistent-subtext}# usato in congiunzione con
-#{persistent}# permetterà supporti persistenti multipli ma univoci. Un
-esempio potrebbe essere un utente che vuole usare una partizione etichettata
-come #{live-sn-sottotesto}#, userebbe: #{persistent}#
-#{persistent-subtext=sottotesto}#.
-
-3~ Rimasterizzazione parziale
-
-Le modifiche in fase di esecuzione del tmpfs possono essere incluse in uno
-squashfs usando live-snapshot e aggiunte al cd per rimasterizzare la iso nel
-caso di un cd riscrivibile o aggiunto ad una sessione di un cd/dvd(rw)
-multisessione; live-boot monta tutti i filesystem /live in ordine o con il
-modulo del parametro d'avvio.
diff --git a/manual/it/user_examples.ssi b/manual/it/user_examples.ssi
deleted file mode 100644
index 3c7c464..0000000
--- a/manual/it/user_examples.ssi
+++ /dev/null
@@ -1,411 +0,0 @@
-:B~ Esempi
-
-1~examples Esempi
-
-Questo capitolo affronta alcune costruzioni di esempio per specifici casi
-d'uso con Debian Live. Se si è nuovi nella costruzione di immagini Debian
-Live, raccomandiamo di dare innanzitutto un'occhiata ai tre tutorial in
-sequenza, dato che ciascuno insegna nuove tecniche che aiuteranno nell'uso e
-nella comprensione degli esempi rimanenti.
-
-2~using-the-examples Usare gli esempi
-
-Per usare questi esempi è necessario un sistema per costruirveli sopra che
-soddisfi i requisiti elencati in {Requisiti}#requirements e avere live-build
-installato come descritto in {Installare live-build}#installing-live-build.
-
-Si noti che, per brevità, in questi esempi non specifichiamo un mirror
-locale da usare per la costruzione. Usando un mirror locale, si possono
-accelerare considerevolmente i download. Si possono specificare le opzioni
-quando si usa #{lb config}#, come descritto in {Mirror delle distribuzioni
-usati in fase di compilazione}#distribution-mirrors-build-time o, più
-convenientemente, impostare il predefinito per il proprio sistema in
-#{/etc/live/build.conf}#. Si crei semplicemente questo file e si impostino
-in esso le corrispondenti variabili #{LB_MIRROR_*}# per il mirror
-desiderato. Ad esempio:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: un'immagine standard
-
-*{Caso d'uso:}* creazione di una prima semplice immagine, imparando i fondamenti di live-build.
-
-In questo tutorial genereremo un'immagine ISO ibrida di Debian Live
-contenente solo pacchetti base (senza Xorg) e alcuni pacchetti Debian Live
-di supporto, come primo esercizio sull'uso di live-build.
-
-Non può essere più semplice:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Esaminare i contenuti della directory #{config/}#; si noterà uno scheletro
-di configurazione pronto per essere personalizzato o, in questo caso, usato
-immediatamente per costruire un'immagine predefinita.
-
-Ora, come super-utente, si generi l'immagine, salvando un log con #{tee}#.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Presupponendo che tutto vada per il verso giusto, dopo un po' la directory
-corrente conterrà #{binary-hybrid.iso}#. Questa immagine ISO ibrida può
-essere avviata direttamente in una macchina virtuale come descritto in
-{Provare un'immagine ISO con Qemu}#testing-iso-with-qemu e {Provare
-un'immagine ISO con virtualbox-ose}#testing-iso-with-virtualbox, oppure
-masterizzata su un supporto ottico o ancora su una chiavetta USB come
-descritto rispettivamente in {Masterizzare un'immagine ISO su un supporto
-fisico}#burning-iso-image e {Copiare un'immagine ISO ibrida su una penna
-USB}#copying-iso-hybrid-to-usb.
-
-2~tutorial-2 Tutorial 2: servizio browser web
-
-*{Caso d'uso:}* creazione di un'immagine per servizio browser web, imparando come applicare le personalizzazioni.
-
-In questo tutorial verrà creata un'immagine adatta all'uso come browser web,
-che serve come introduzione alla personalizzazione delle immagini Debian
-Live.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-La scelta di LXDE per questo esempio riflette il desiderio di fornire un
-ambiente desktop minimale, dato che il punto focale dell'immagine è il
-singolo uso che abbiamo in mente, il browser web. Potremmo anche spingerci
-oltre e fornire una configurazione predefinita per il browser web in
-#{config/chroot_local-includes/etc/iceweasel/profile/}#, o pacchetti
-addizionali di supporto per la fruizione di vari tipi di contenuti web, ma
-lasciamo questo come esercizio per il lettore.
-
-Si generi l'immagine, ancora come super-utente, conservando un log come in
-{Tutorial 1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Di nuovo, si verifichi che l'immagine sia a posto e la si collaudi, come in
-{Tutorial 1}#tutorial-1.
-
-2~tutorial-3 Tutorial 3: un'immagine personalizzata
-
-*{Caso d'uso:}* creazione di un progetto per costruire un'immagine personalizzata che contiene i pacchetti preferiti da portare con sé in una chiavetta USB ovunque si vada, e che evolve in revisioni successive allorché i bisogni o le preferenze cambino.
-
-Dal momento che la nostra immagine personalizzata cambierà con le successive
-revisioni, e che vogliamo tener traccia di questi cambiamenti, andando per
-tentativi ed eventualmente tornando indietro se qualcosa non funziona,
-conserveremo la nostra configurazione nel popolare sistema di controllo di
-versione #{git}#. Useremo anche le migliori pratiche di auto-configurazione
-tramite gli script #{auto}# come descritto in {Gestire una
-configurazione}#managing-a-configuration.
-
-3~ Prima revisione
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Modificare #{auto/config}# come segue:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-Per prima cosa, #{--architecture i386}# assicura che sul nostro sistema
-#{amd64}# costruiamo una versione a 32-bit utilizzabile sulla maggior parte
-delle macchine. In secondo luogo, usiamo #{--linux-flavours 686}# dato che
-non prevediamo di usare questa immagine su sistemi troppo vecchi. Terzo,
-abbiamo scelto la lista di pacchetti #{lxde}# per avere un desktop
-minimale. Infine, abbiamo aggiunto due pacchetti preferiti per cominciare:
-#{iceweasel}# e #{xchat}#.
-
-Costruire quindi l'immagine:
-
-code{
-
- # lb build
-
-}code
-
-Si noti che diversamente dai primi due tutorial, non occorre più digitare
-#{2>&1 | tee binary.log}# dato che questo è ora incluso in #{auto/build}#.
-
-Una volta che l'immagine è stata collaudata (come in {Tutorial
-1}#tutorial-1) e che si è sicuri che funzioni correttamente, è il momento di
-inizializzare il repository #{git}#, aggiungendo solo gli script auto appena
-creati, e di fare poi il primo commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Seconda revisione
-
-In questa revisione ripuliremo la prima compilazione, aggiungeremo il
-pacchetto #{vlc}# alla configurazione, dunque avverrà una ricompilazione,
-verifica e commit.
-
-Il comando #{lb clean}# ripulirà tutti i file ottenuti con la precedente
-generazione eccetto la cache, che ci evita un nuovo download dei
-pacchetti. Ciò assicura che il successivo #{lb build}# eseguirà di nuovo
-tutti i passaggi per rigenerare i file dalla nuova configurazione.
-
-code{
-
- # lb clean
-
-}code
-
-Si modifichi ora #{auto/config}# per aggiungere il pacchetto #{vlc}#:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Rigenerare nuovamente:
-
-code{
-
-# lb build
-
-}code
-
-Verificare, e quando soddisfatti, eseguire il commit della revisione
-successiva:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Ovviamente sono possibili cambiamenti alla configurazione più complicati,
-magari aggiungendo file in sottodirectory di #{config/}#. Quando si esegue
-il commit di nuove revisioni, si faccia solo attenzione a non modificare
-manualmente o fare un commit dei file al livello superiore di #{config}# che
-contengono le variabili #{LB_*}#, giacché sono anche prodotti
-dell'assemblaggio, e che sono sempre ripuliti da #{lb clean}# e ricreati con
-#{lb config}# attraverso i loro rispettivi script #{auto}#.
-
-Siamo arrivati alla fine di questa serie di tutorial. Mentre sono possibili
-molti altri tipi di personalizzazioni, anche solo usando le poche
-caratteristiche esplorate in questi semplici esempi, può essere creata una
-varietà quasi infinita di immagini. Gli esempi rimanenti in questa sezione
-coprono diversi altri casi d'uso estrapolati dalle esperienze raccolte degli
-utenti Debian Live.
-
-2~ Un client Kiosk VNC
-
-*{Caso d'uso:}* creazione di un'immagine con live-build per avviare direttamente un server VNC.
-
-Creare una directory con al suo interno una configurazione scheletrica
-costruita sulla base dell'elenco di standard-x11, tra cui #{gdm3}#,
-#{metacity}# e #{xtightvncviewer}#, disabilitando i raccomandati per
-ottenere un sistema minimale:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Creare la directory #{/etc/skel}# e inserirvi un #{.xsession}#
-personalizzato per l'utente predefinito che lancerà metacity e avvierà
-xvncviewer, connesso alla porta #{5901}# su un server all'indirizzo
-#{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Costruire l'immagine:
-
-code{
-
- # lb build
-
-}code
-
-Buon divertimento.
-
-2~ Un'immagine base per una chiavetta USB da 128M
-
-*{Caso d'uso:}* creazione di un'immagine standard con alcuni componenti rimossi affinché possa stare su una chiavetta USB da 128M, con lo spazio che rimane da usarsi come meglio si crede.
-
-Quando si cerca di ottimizzare un'immagine affinché sia contenuta in un
-supporto, è necessario capire il compromesso che si deve fare tra la
-dimensione e la funzionalità. In questo esempio, taglieremo solo quanto
-basta per far sì che il tutto stia in 128M, senza fare nient'altro che
-distrugga l'integrità dei pacchetti contenuti, come eliminare localizzazioni
-con il pacchetto #{localepurge}# o altre ottimizzazioni "intrusive". È da
-notare che non va usato #{--bootstrap-flavour minimal}# a meno che non si
-sappia cosa si sta facendo, come omettere la priorità dei pacchetti
-#{important}# che molto probabilmente produrrà un sistema live danneggiato.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Costruire quindi l'immagine nel modo consueto:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-All'autore del sistema al momento di scrivere, la seguente configurazione ha
-prodotto una immagine di 78Mbyte. Comparabile favorevolmente con i 166Mbyte
-prodotta dalla configurazione predefinita nel {Tutorial 1}#tutorial-1.
-
-Ciò che salva più spazio, comparato alla costruzione di un'immagine standard
-su un sistema con architettura #{i386}#, è la selezione del solo kernel
-#{486}# invece che quello predefinito #{-k "486 686"}#. Lasciando fuori
-anche gli indici di APT con #{--binary-indices false}# si può salvare una
-certa quantità di spazio, il compromesso è usare #{apt-get update}# prima di
-usare apt nel sistema live. Scegliendo la lista #{minima}# dei pacchetti si
-esclude il grosso pacchetto #{locales}# e le utilità associate. Saltare i
-pacchetti raccomandati con #{--apt-recommends false}# salva altro spazio, a
-scapito di alcuni pacchetti che ci si aspetta di trovare, come
-#{firmware-linux-free}# che potrebbe servire a supportare un certo
-hardware. Le restanti opzioni limano altre piccole quantità di spazio. Sta a
-voi decidere se le funzionalità sacrificate con ciascuna ottimizzazione
-valgono la pena.
-
-2~ Un desktop KDE localizzato e l'installer
-
-*{Caso d'uso:}* creazione di un'immagine con il desktop KDE, localizzato per il portoghese brasiliano e che includa l'installatore.
-
-Si vuole creare un'immagine iso ibrida per architettura i386 usando il
-nostro desktop preferito, in questo caso KDE, contenente tutti gli stessi
-pacchetti che verrebbero installati dall'installatore Debian standard per
-KDE.
-
-Il problema iniziale è di scoprire i nomi dei task appropriati, attualmente,
-live-build non aiuta in questo. Si può essere fortunati o arrivarci con vari
-tentativi, ma c'è uno strumento #{grep-dctrl}# il quale può essere
-utilizzato per scavare nelle descrizioni in tasksel-data, perciò assicursi
-di avere entrambi questi pacchetti:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Ora si possono cercare i task appropriati:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-Con questo comando, si è scoperto che il task si chiama, abbastanza
-chiaramente, brazilian-portuguese. Ora per trovare i task correlati:
-
-code{
-
- $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-Si userà l'opzione sperimentale #{--language}#, poiché live-build contempla
-i template #{syslinux}# per pt_BR (vedere {Task per desktop e
-lingua}#desktop-and-language-tasks per i dettagli). All'avvio verrà generata
-la lingua pt_BR.UTF-8 e selezionato pt-latin1 come layout della
-tastiera. Ora mettiamo insieme i pezzi:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Si noti che è stato incluso il pacchetto #{debian-installer-launcher}# in
-modo da poter lanciare l'installer dal desktop della live, e che è stato
-anche specificato il kernel 486, dato che attualmente è necessario che il
-kernel dell'installer e quello del sistema live coincidano affinché il
-launcher funzioni correttamente.
diff --git a/manual/it/user_installation.ssi b/manual/it/user_installation.ssi
deleted file mode 100644
index ffeb180..0000000
--- a/manual/it/user_installation.ssi
+++ /dev/null
@@ -1,179 +0,0 @@
-:B~ Installazione
-
-1~installation Installazione
-
-2~requirements Requisiti
-
-Per costruire immagini Debian Live i requisiti di sistema sono davvero
-pochi:
-
-_* Accesso come super-utente (root)
-
-_* Una versione aggiornata di live-build
-
-_* Una shell POSIX-compliant, come /{bash}/ o /{dash}/.
-
-_* /{debootstrap}/ o /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Si noti che usare Debian o una distribuzione derivata Debian non è richiesto
-- live-build funzionerà sostanzialmente su qualsiasi distribuzione che
-soddisfi i requisiti di cui sopra.
-
-2~installing-live-build Installare live-build
-
-Si può installare live-build in diversi modi:
-
-_* Dal repository Debian
-
-_* Da sorgenti
-
-_* Da istantanee
-
-Se si sta usando Debian, il metodo raccomandato è di installare live-build
-attraverso il repository Debian.
-
-3~ Dal repository Debian
-
-Installare live-build semplicemente come qualsiasi altro pacchetto:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-o
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ Da sorgenti
-
-live-build è sviluppato usando il sistema di controllo versione Git. Sui
-sistemi basati su Debian è fornito dal pacchetto /{git}/. Per scaricare il
-codice aggiornato, eseguire:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-È possibile costruirsi ed installarsi il proprio pacchetto Debian eseguendo:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Si installino ora i file #{.deb}# appena generati ai quali si è interessati,
-ad esempio:
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-Si può anche installare live-build direttamente sul proprio sistema
-eseguendo:
-
-code{
-
- # make install
-
-}code
-
-e disinstallarlo con:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ Da "istantanee"
-
-Se non si desidera generare o installare live-build da sorgenti, è possibile
-usare le istantanee. Sono costruite automaticamente dall'ultima versione
-presente su Git e disponibili su http://live.debian.net/debian/.
-
-2~ live-boot e live-config
-
-*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes. If you only want the documentation, you may now install the live-boot-doc and live-config-doc packages separately.
-
-3~ Dal repository Debian
-
-Sia live-boot che live-config sono disponibili dai repository Debian come
-per l'{installazione di live-build}#installing-live-build.
-
-3~ Da sorgenti
-
-Per utilizzare i sorgenti più recenti da Git si può seguire il procedimento
-seguente. Assicurarsi di conoscere i termini menzionati nel
-{Glossario}#terms.
-
-_* Scaricare i sorgenti di live-boot e live-config
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Consultare la pagine man di live-boot e live-config per i dettagli sulla
-personalizzazione se questa è il motivo per compilare questi pacchetti dai
-sorgenti.
-
-_* Costruire un .deb di live-boot e live-config
-
-È necessario compilare sulla distribuzione di destinazione, oppure in un
-chroot contenente la piattaforma di destinazione: significa che se
-l'obiettivo è Squeeze allora bisogna compilare su Squeeze.
-
-Se si deve compilare #{live-boot}# per una distribuzione di destinazione
-diversa dal proprio sistema, utilizzare un compilatore tipo /{pbuilder}/ o
-/{sbuild}/. Ad esempio, per immagini live Squeeze, si generi #{live-boot}#
-in un chroot Squeeze. Se la distribuzione di destinazione corrisponde con la
-distribuzione del proprio sistema, si può costruire direttamente sul sistema
-usando #{dpkg-buildpackage}# (fornito dal pacchetto /{dpkg-dev}/):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Usare il .deb di live-boot generato
-
-Siccome live-boot e live-config sono installati dal sistema live-build,
-installare il pacchetto nel sistema host non è sufficiente: occorre trattare
-il .deb generato come un qualsiasi altro pacchetto creato su misura. Per
-maggiori informazioni si veda {Personalizzare l'installazione dei
-pacchetti}#customizing-package-installation. Si presti particolare
-attenzione a {Repository aggiuntivi}#additional-repositories.
-
-3~ Da "istantanee"
-
-You can let live-build automatically use the latest snapshots of live-boot
-and live-config by configuring a third-party repository in your live-build
-configuration directory. Assuming you have already created a configuration
-tree in the current directory with #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/it/user_managing_a_configuration.ssi b/manual/it/user_managing_a_configuration.ssi
deleted file mode 100644
index 956f64d..0000000
--- a/manual/it/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,94 +0,0 @@
-:B~ Gestire una configurazione
-
-1~managing-a-configuration Gestire una configurazione
-
-Questo capitolo spiega come gestire una configurazione per una live sin
-dalla creazione iniziale, attraverso le successive revisioni e rilasci sia
-del software live-build che della stessa immagine live.
-
-2~ Utilizzare auto per gestire i cambiamenti di configurazione
-
-Le configurazioni live raramente sono perfette da riuscire al primo
-colpo. Servono una serie di revisioni prima di essere soddisfatti. Comunque,
-possono verificarsi delle incoerenze tra una revisione ed un'altra se non si
-presta attenzione. Il problema principale è, una volta che ad una variabile
-è assegnato un valore predefinito, tale valore non sarà ricalcolato da altre
-variabili che possono cambiare in altre revisioni.
-
-Per esempio, durante la messa a punto della prima distribuzione, molte
-variabili 'dependent' sono date dalle caratteristiche della
-distribuzione. Quindi, se in seguito si decide di cambiare distribuzione,
-quelle variabili dipendenti continueranno a mantenere i vecchi valori i
-quali non sono più appropriati
-
-Un secondo relativo problema è che se si lancia #{lb config}# e si è
-aggiornato live-build ad una nuova versione il quale ha cambiato il nome di
-una o più variabili, si può scoprire ciò solamente con una revisione manuale
-delle variabili nei file #{config/*}#, bisogna che vengano risistemate, di
-nuovo, le appropriate opzioni.
-
-Tutto ciò potrebbe essere un fastidio terribile se non fosse per lo script
-auto/*, una semplice alternativa ai comandi #{lb config}#, #{lb build}# e
-#{lb clean}# che sono disegnati per aiutare nella gestione della
-configurazione. Basta creare un semplice script auto/config che contenga il
-comando #{lb config}# con le opzioni desiderate, e un auot/clean che rimuova
-i file contenenti i valori variabili di configurazione, cosi ogni volta
-saranno eseguiti #{lb config}# #{lb clean}#. Questo farà si che la
-configurazione sia sempre coerente da una revisione all'altra o dal rilascio
-delle varie versioni del live-build.
-
-2~ Esempi di auto script
-
-Usare esempi di auto script come il seguente come punto di partenza per una
-nuova configurazione di live-build. Prendere nota che quando si chiama il
-comando #{lb}# che l'auto script wraps, si deve specificare il parametro
-#{noauto}# per essere sicuri che l'auto script chiamato di nuovo
-ricorsivamente. Non dimenticare, inoltre, di rendere lo script eseguibile
-(es. #{chmod 755 auto/*}#).
-
-#{auto/config}#
-
-code{
-
- #!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-Facciamo un esempio di auto script per live-build basato sull'esempio
-precedente. Si possono copiare come punto di partenza.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Modifica #{auto/config}# aggiungendo o togliendo le opzioni come meglio
-credi. Nel precedente esempio #{--packages-lists standard}# è impostato il
-valore predefinito.Cambiare questo in un valore appropriato per l'immagine (
-o cancellarlo se si desidera utilizzare un valore predefinito) e aggiungere
-eventuali opzioni aggiuntive in continuazione delle righe che seguono.
diff --git a/manual/it/user_overview.ssi b/manual/it/user_overview.ssi
deleted file mode 100644
index a082cd4..0000000
--- a/manual/it/user_overview.ssi
+++ /dev/null
@@ -1,163 +0,0 @@
-:B~ Panoramica degli strumenti
-
-1~overview-of-tools Panoramica degli strumenti
-
-Questo capitolo contiene una panoramica dei tre principali strumenti
-utilizzati nella creazione dei sistemi Debian Live: live-build, live-boot e
-live-config.
-
-2~live-build live-build
-
-live-build è una raccolta di script, chiamati anche "comandi", usati per
-creare sistemi Debian Live.
-
-L'idea dietro live-build è di essere un'infrastruttura che utilizza una
-directory di configurazione per automatizzare totalmente e personalizzare
-tutti gli aspetti della creazione di un'immagine live.
-
-Molti concetti sono simili a quelli negli strumenti del pacchetto Debian
-debhelper scritto da Joey Hess:
-
-_* Gli script hanno una locazione centrale per configurare le loro
-operazioni, in debhelper questa è la sottodirectory #{debian/}# dell'albero
-di un pacchetto. Ad esempio dh_install cercherà, tra gli altri, un file
-chiamato #{debian/install}# per determinare quali file dovrebbero esistere
-in un certo pacchetto binario. Allo stesso modo, live-build salva la sua
-configurazione interamente in una sottodirectory #{config/}#.
-
-_* Gli script sono indipendenti, vale a dire che è sempre sicuro eseguire
-ogni comando.
-
-Al contrario di debhelper, live-build contiene uno strumento per generare
-una directory scheletro di configurazione, #{lb config}#, che può essere
-considerato simile a utilità come #{dh-make}#. Per maggiori informazioni su
-#{lb config}# si veda {Il comando lb config}#lb-config.
-
-Il resto di questa sezione tratta i tre comandi più importanti:
-
-_* *{lb config}*: responsabile dell'inizializzazione di una directory di
-configurazione del sistema live. Si veda {Il comando lb config}#lb-config
-per maggiori informazioni.
-
-_* *{lb build}*: responsabile di iniziare la creazione di un sistema
-live. Si veda {Il comando lb}#lb-build per maggiori informazioni.
-
-_* *{lb clean}*: responsabile della rimozione di parti della creazione di un
-sistema live. Si veda {Il comando lb clean}#lb-clean per maggiori
-informazioni.
-
-3~lb-config Il comando #{lb config}#
-
-Come discusso in {live-build}#live-build, gli script che compongono
-live-build attingono la loro configurazione con il comando #{source}# da una
-singola directory chiamata #{config/}#. Dal momento che crearla a mano
-sarebbe dispendioso in termini di tempo e soggetto a errori, si può usare il
-comando #{lb config}# per creare la directory scheletro di configurazione.
-
-L'esecuzione di #{lb config}# senza argomenti crea una sottodirectory di
-#{config/}# popolata con alcune impostazioni predefinite:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-L'uso di #{lb config}# senza argomenti è adatto ad utenti che necessitano di
-un'immagine di base o che intendono fornire in seguito una configurazione
-più completa tramite auto/config (per i dettagli vedere {Gestire una
-configurazione}#managing-a-configuration).
-
-Normalmente si vorranno specificare delle opzioni, ad esempio per includere
-nella propria configurazione l'elenco del pacchetto "gnome":
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-È possibile specificare molte opzioni, come:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-Una lista completa delle opzioni è disponibile nel manuale di #{lb_config}#.
-
-3~lb-build Il comando #{lb build}#
-
-Il comando #{lb build}# legge la configurazione dalla directory #{config/}#
-ed esegue ad un livello inferiore i comandi necessari a costruire il sistema
-live.
-
-3~lb-clean Il comando #{lb clean}#
-
-È compito del comando #{lb clean}# rimuovere le varie parti di una
-compilazione in modo che le successive possano iniziare da uno stato
-pulito. Per impostazione predefinita, vengono pulite le fasi #{chroot}#,
-#{binary}# e #{source}# ma la cache viene lasciatta intatta. Le fasi possono
-inoltre essere pulite singolarmente; ad esempio se sono state fatte
-modifiche alla sola fase binaria, si usi #{lb clean --binary}# prima di
-compilare un nuovo binario. Per la lista completa delle opzioni vedere la
-pagina di manuale di #{lb_clean}#.
-
-2~live-boot Il pacchetto live-boot
-
-live-boot è una raccolta di script che forniscono hook per initramfs-tools,
-utilizzato per generare un initramfs in grado di avviare sistemi live, come
-quelli creati da live-build. Questo include le ISO di Debian Live, archivi
-per l'avvio da rete e immagini per penne USB.
-
-All'avvio cercherà supporti in sola lettura che contengano una directory
-"/live" dove sia presente un filesystem root (spesso un'immagine compressa
-come squashfs). Se trovata, creerà un ambiente scrivibile usando aufs, per
-avviarsi da sistemi simili a Debian.
-
-Si possono trovare maggiori informazioni sui ramfs iniziali nel capitolo su
-initramfs del Debian Linux Kernel Handbook all'indirizzo
-http://kernel-handbook.alioth.debian.org/.
-
-2~live-config Il pacchetto live-config
-
-live-config è costituito da script eseguiti all'avvio dopo live-boot per
-configurare automaticamente il sistema live. Gestisce attività quali
-impostare l'hostname, localizzazione e fuso orario, creare l'utente live,
-inibire compiti automatizzati tramite cron ed eseguire il login automatico
-dell'utente live.
diff --git a/manual/po/it/user_installation.ssi.po b/manual/po/it/user_installation.ssi.po
index 867b814..6818bbd 100644
--- a/manual/po/it/user_installation.ssi.po
+++ b/manual/po/it/user_installation.ssi.po
@@ -366,10 +366,8 @@ msgstr "2~ live-boot e live-config"
#. type: Plain text
#: en/user_installation.ssi:102
-#, fuzzy, no-wrap
-#| msgid "*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes.\n"
msgid "*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes. If you only want the documentation, you may now install the live-boot-doc and live-config-doc packages separately.\n"
-msgstr "*{Nota:}* non è necessario installare live-boot o live-config sul proprio sistema per creare sistemi Debian Live personalizzati. Tuttavia, farlo non nuoce.\n"
+msgstr "*{Nota:}* non è necessario installare live-boot o live-config sul proprio sistema per creare sistemi Debian Live personalizzati. Tuttavia, farlo non nuoce. Se si vuole la documentazione è possibile installare i pacchetti live-boot-doc e live-config-doc separatamente.\n"
#. type: Plain text
#: en/user_installation.ssi:106
@@ -480,12 +478,6 @@ msgstr ""
#. type: Plain text
#: en/user_installation.ssi:144
-#, fuzzy
-#| msgid ""
-#| "You can let live-build automatically use the latest snapshots of live-"
-#| "boot and live-config by configuring a third-party repository in your live-"
-#| "build configuration directory. Assuming you have already created a "
-#| "configuration tree with #{lb config}#:"
msgid ""
"You can let live-build automatically use the latest snapshots of live-boot "
"and live-config by configuring a third-party repository in your live-build "
@@ -495,7 +487,7 @@ msgstr ""
"Si può lasciare che live-build usi automaticamente l'ultima istantanea di "
"live-boot e live-config configurando un repository esterno nella directory "
"di configurazione di live-build. Assumendo che si sia già creato un albero "
-"di configurazione con #{lb config}#:"
+"di configurazione nell'attuale directory con #{lb config}#:"
#. type: Plain text
#: en/user_installation.ssi:148
diff --git a/manual/po4a.cfg b/manual/po4a.cfg
deleted file mode 100644
index b09d7e4..0000000
--- a/manual/po4a.cfg
+++ /dev/null
@@ -1,20 +0,0 @@
-[po4a_langs] de es fr it pt_BR ro
-[po4a_paths] pot/$master.pot $lang:po/$lang/$master.po
-[type: text] en/live-manual.ssm $lang:$lang/live-manual.ssm
-[type: text] en/about_manual.ssi $lang:$lang/about_manual.ssi
-[type: text] en/about_project.ssi $lang:$lang/about_project.ssi
-[type: text] en/project_bugs.ssi $lang:$lang/project_bugs.ssi
-[type: text] en/project_coding-style.ssi $lang:$lang/project_coding-style.ssi
-[type: text] en/project_procedures.ssi $lang:$lang/project_procedures.ssi
-[type: text] en/user_basics.ssi $lang:$lang/user_basics.ssi
-[type: text] en/user_customization-binary.ssi $lang:$lang/user_customization-binary.ssi
-[type: text] en/user_customization-contents.ssi $lang:$lang/user_customization-contents.ssi
-[type: text] en/user_customization-installer.ssi $lang:$lang/user_customization-installer.ssi
-[type: text] en/user_customization-overview.ssi $lang:$lang/user_customization-overview.ssi
-[type: text] en/user_customization-packages.ssi $lang:$lang/user_customization-packages.ssi
-[type: text] en/user_customization-runtime.ssi $lang:$lang/user_customization-runtime.ssi
-[type: text] en/user_examples.ssi $lang:$lang/user_examples.ssi
-[type: text] en/user_installation.ssi $lang:$lang/user_installation.ssi
-[type: text] en/user_managing_a_configuration.ssi $lang:$lang/user_managing_a_configuration.ssi
-[type: text] en/user_overview.ssi $lang:$lang/user_overview.ssi
-[type: xhtml] en/index.html.in $lang:$lang/index.html.in
diff --git a/manual/pt_BR/_sisu/.empty b/manual/pt_BR/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/pt_BR/_sisu/image/.empty b/manual/pt_BR/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/pt_BR/_sisu/sisurc.yml b/manual/pt_BR/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/pt_BR/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/pt_BR/_sisu/skin/doc/skin_debian-live.rb b/manual/pt_BR/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/pt_BR/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/pt_BR/about_manual.ssi b/manual/pt_BR/about_manual.ssi
deleted file mode 100644
index 0ef9e7f..0000000
--- a/manual/pt_BR/about_manual.ssi
+++ /dev/null
@@ -1,274 +0,0 @@
-:B~ Sobre esse manual
-
-1~about-manual Sobre esse manual
-
-The main goal of this manual is to serve as a single access point to all
-documentation related to the Debian Live project. While it is primarily
-focused on helping you build a live system and not on end-user topics, an
-end-user may find some useful information in these sections: {The
-Basics}#the-basics covers preparing images to be booted from media or the
-network, and {Customizing run time
-behaviours}#customizing-run-time-behaviours describes some options that may
-be specified at the boot prompt, such as selecting a keyboard layout and
-locale, and using persistence.
-
-Alguns comandos mencionados no texto devem ser executados com privilégios de
-super-usuário, que podem ser obtidos tornando-se usuário root via #{su}# ou
-usando #{sudo}#. Para distinção entre os comandos que talvez possam ser
-executados como usuário não privilegiado e aqueles que requerem privilégios
-de super usuário, os comandos são precididos por: #{$}# ou #{#}#
-respectivamente. Esse simbolo não é parte do comando.
-
-2~ For the impatient
-
-While we believe that everything in this manual is important to at least
-some of our users, we realize it is a lot of material to cover and that you
-may wish to experience early success using the software before delving into
-the details. Therefore, we have provided three tutorials in the
-{Examples}#examples section designed to teach you image building and
-customization basics. Read {Using the examples}#using-the-examples first,
-followed by {Tutorial 1: A standard image}#tutorial-1, {Tutorial 2: A web
-browser utility}#tutorial-2 and finally {Tutorial 3: A personalized
-image}#tutorial-3. By the end of these tutorials, you will have a taste of
-what can be done with Debian Live. We encourage you to return to more
-in-depth study of the manual, perhaps next reading {The basics}#the-basics,
-skimming or skipping {Building a netboot image}#building-netboot-image, and
-finishing by reading the {Customization overview}#customization-overview and
-the chapters that follow it. By this point, we hope you are thoroughly
-excited by what can be done with Debian Live and motivated to read the rest
-of the manual, cover-to-cover.
-
-2~terms Terminologia
-
-_* *{Live system}*: Um sistema operacional que pode inicializar sem
-instalação em um disco rígido. Sistemas live não devem alterar o(s)
-sistema(s) operacional(s) local(is) ou arquivo(s) já instalados no disco
-rígido do computador a não ser que seja instruido para isso. Sistemas Live
-são tipicamente inicializados a partir de uma mídia como CDs, DVDs ou
-pendrive(s). Alguns também podem inicializar através da rede.
-
-_* *{Debian Live}*: O sub-projeto Debian que manten os pacotes live-boot,
-live-build, live-config, e live-manual.
-
-_* *{Debian Live system}*: Um sistema live que usa softwares do sistema
-operacional Debian que também pode ser inicializado a partir de CD's, DVDs,
-Discos USB, através da rede (via imagens netbook), e através da Internet
-(via parametro de boot #{fetch=URL}#).
-
-_* *{Host system}*: O ambiente usado para criar o sistema live.
-
-_* *{Target system}*: O ambiente usado para rodar o sistema live.
-
-_* *{live-boot}*: Uma coleção de scripts usados para inicializar sistemas
-live. live-boot era formalmente parte do live-initramfs.
-
-_* *{live-build}*: Uma coleção de scripts usados para construir sistemas
-Debian live customizados. live-build era formalmente conhecido como
-live-helper, e ainda antes conhecido como live-package.
-
-_* *{live-config}*: Uma coleção de scripts usados para configurar um sistema
-live durante o processo de boot. live-config era formalmente parte do
-live-initramfs.
-
-_* *{live-manual}*: Esse documento é mantido em um pacote chamado
-live-manual.
-
-_* *{Debian Installer (d-i)}*: O sistema oficial de instalação para a
-distribuição Debian.
-
-_* *{Boot parameters}*: Parametros que podem ser entrados no prompt do
-bootloader para influenciar o kernel ou o live-config.
-
-_* *{chroot}*: O programa chroot, #{chroot(8)}#, nos habilita a rodar
-simultâneamente diferentes instâncias do ambiente do GNU/Linux em um único
-sistema sem reinicialização.
-
-_* *{Binary image}*: Um arquivo contendo o sistema live, como binary.iso ou
-binary.img.
-
-_* *{Target distribution}*: A distribuição em que o sistema live será
-baseado. Isso pode diferir da distribuição do seu sistema host.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Debian codenames for
-releases. At the time of writing, Squeeze is the current *{stable}* release
-and Wheezy is the current *{testing}* release. Sid will always be a synonym
-for the *{unstable}* release. Throughout the manual, we tend to use
-codenames for the releases, as that is what is supported by the tools
-themselves.
-
-A distribuição estável (*{stable}*) contem a última versão oficial lançada
-do Debian. A distribuição *{testing}* é a ária de estágio para a próxima
-versão estável(stable). A maior vantagem de usar essa distribuição é que ela
-tem versões mais recentes de software relacionado com a versão estável
-(*{stable}*). A distribuição instável (*{unstable}*) é onde ocorre o
-desenvolvimento ativo do Debian. Geralmente, essa distribuição é mantida por
-desenvolvedores e aqueles que vivem no limite.
-
-2~Autores
-
-A lista de autores (em ordem alfabética)
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Contribuindo com esse documento
-
-This manual is intended as a community project and all proposals for
-improvements and contributions are extremely welcome. The preferred way to
-submit a contribution is to send it to the mailing list. Please see the
-section {Contact}#contact for more information.
-
-Quando estiver submetendo uma contribuição, por favor identificar claramente
-o seu titular de direitos autorais e incluir a declaração de
-licenciamento. Note que para ser aceita, a contribuição deve ser licenciada
-obre as mesmas licenças do resto do documento, ou seja, GPL versão 3 ou
-superior.
-
-Os fontes para esse manail são mantidos usando o sistema de controle de
-versão Git. Você pode fazer o checkout da ultima cópia executando:
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Antes de submeter sua contribuição, por favor pré-visualize seu
-trabalho. Para pré-visualizar o live-manual, tenha certeza que os pacotes
-necessários para contruir estão instalados executando:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-Você também pode construir o live-manual a partir do primeiro nível do
-diretório do seu Git checkout executando:
-
-code{
-
- $ make build
-
-}code
-
-Since it takes a while to build the manual in all supported languages, you
-may find it convenient when proofing to build for only one language, e.g. by
-executing:
-
-code{
-
- $ make build LANGUAGES=en
-
-}code
-
-3~ Aplicando patches
-
-Diretamente cometer ao repoitório é possivel por qualquer um. No entanto,
-nós pedimo que você mande maiores mudanças para a lista de e-mail para
-discuti-las primeiro. Para enviar ao repositório, os seguintes passos são
-necessários:
-
-_* Obter a chave publica de commit:
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Adicione a seguinte sessão na configuração do seu openssh-client:
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Fazer o checkout de um clone do manual por ssh:
-
-code{
-
- $ git clone gitosis at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Note that you should commit any changes on the debian-next branch, not on
-the debian branch.
-
-_* Depois de editar os arquivos no manual/en/, por favor chame o alvo
-'commit' no nível superior do diretório para higiênizar os arquivos e
-atualizar os arquivos de tradução.
-
-code{
-
- $ make commit
-
-}code
-
-_* Depois de higiênizar submeta as mudançãs. Escreva mensagens de submissão,
-que consistem em sentanças completas úteis, começando por letra maiuscula e
-acabando com uma parada total. Normalmente iniciando com as formas
-'Fixing/Adding/Removing/Correcting/Translating'.
-
-code{
-
- $ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Enviar as submissões para os servidor.
-
-code{
-
- $ git push
-
-}code
-
-3~ Translation
-
-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.
-
-_* Once the new language is added, you can randomly start translating all po
-files in #{manual/po/}#.
-
-_* Don't forget you need #{make commit}# to ensure the translated manuals
-are updated from the po files, before #{git commit -a}# and #{git push}#.
diff --git a/manual/pt_BR/about_project.ssi b/manual/pt_BR/about_project.ssi
deleted file mode 100644
index 71c6174..0000000
--- a/manual/pt_BR/about_project.ssi
+++ /dev/null
@@ -1,107 +0,0 @@
-B~ Sobre o Projeto Debian Live
-
-1~about-project About the Debian Live Project
-
-2~ Motivation
-
-3~ What is wrong with current live systems
-
-When Debian Live was initiated, there were already several Debian based live
-systems available and they are doing a great job. From the Debian
-perspective most of them have one or more of the following disadvantages:
-
-_* They are not Debian projects and therefore lack support from within
-Debian.
-
-_* They mix different distributions, e.g. *{testing}* and *{unstable}*.
-
-_* They support i386 only.
-
-_* They modify the behaviour and/or appearance of packages by stripping them
-down to save space.
-
-_* They include packages from outside of the Debian archive.
-
-_* They ship custom kernels with additional patches that are not part of
-Debian.
-
-_* They are large and slow due to their sheer size and thus not suitable for
-rescue issues.
-
-_* They are not available in different flavours, e.g. CDs, DVDs, USB-stick
-and netboot images.
-
-3~ Why create our own live system?
-
-Debian is the Universal Operating System: Debian has a live system to show
-around and to accurately represent the Debian system with the following main
-advantages:
-
-_* It would be a subproject of Debian.
-
-_* It reflects the (current) state of one distribution.
-
-_* It runs on as many architectures as possible.
-
-_* It consists of unchanged Debian packages only.
-
-_* It does not contain any packages that are not in the Debian archive.
-
-_* It uses an unaltered Debian kernel with no additional patches.
-
-2~ Philosophy
-
-3~ Only unchanged packages from Debian "main"
-
-We will only use packages from the Debian repository in the "main"
-section. The non-free section is not part of Debian and therefore cannot be
-used for official live system images.
-
-We will not change any packages. Whenever we need to change something, we
-will do that in coordination with its package maintainer in Debian.
-
-As an exception, our own packages such as live-boot, live-build or
-live-config may temporarily be used from our own repository for development
-reasons (e.g. to create development snapshots). They will be uploaded to
-Debian on a regular basis.
-
-3~ No package configuration of the live system
-
-In this phase we will not ship or install sample or alternative
-configurations. All packages are used in their default configuration as they
-are after a regular installation of Debian.
-
-Whenever we need a different default configuration, we will do that in
-coordination with its package maintainer in Debian.
-
-A system for configuring packages is provided using debconf in #{lb config}#
-(use --preseed FILE) allowing custom configured packages to be installed in
-your custom produced Debian Live images, but for official live images only
-default configuration will be used. For more information, please see
-{Customization overview}#customization-overview.
-
-Exception: There are a few essential changes needed to bring a live system
-to life (e.g. configuring pam to allow empty passwords). These essential
-changes have to be kept as minimal as possible and should be merged within
-the Debian repository if possible.
-
-2~contact Contact
-
-_* *{Mailing list}*: The primary contact for the project is the mailing list
-at http://lists.debian.org/debian-live/. You can email the list directly by
-addressing your mail to debian-live at lists.debian.org. The list archives are
-available at http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: A number of users and developers are present in the #debian-live
-channel on irc.debian.org (OFTC). When asking a question on IRC, please be
-patient for an answer. If no answer is forthcoming, please email the mailing
-list.
-
-_* *{BTS}*: The Debian Bug Tracking System (BTS) contains details of bugs
-reported by users and developers. Each bug is given a number, and is kept on
-file until it is marked as having been dealt with. For more information,
-please see {Reporting bugs}#bugs.
-
-_* *{Wiki}*: The Debian Live wiki at http://wiki.debian.org/DebianLive is a
-place to gather information, discuss applied technologies, and document
-frameworks of Debian Live systems that go beyond the scope of this document.
diff --git a/manual/pt_BR/index.html.in b/manual/pt_BR/index.html.in
deleted file mode 100644
index f187810..0000000
--- a/manual/pt_BR/index.html.in
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-
-<head>
- <title>Projeto Debian Live</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Manual do Debian Live</h2>
-
- <p>
- Por favor reporte erros, omissões, patches e sugestões para nossa lista de
-discussão em <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>
-e leia sobre <a href="html/about-manual.html#how-to-contribute">como
-contribuir</a> com o manual.
- </p>
-
- <h3>Formatos Disponíveis</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">Páginas multiplas</a>, <a
-href="html/live-manual.html">Página única</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 retrato</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 paisagem</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">US retrato</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">US paisagem</a></li>
- <li><a href="txt/live-manual.txt">Texto plano</a></li>
- </ul>
-
- <p>
- Última modificação: @DATE_CHANGE@<br />
- Última contrução: @DATE_BUILD@
- </p>
-
- <h3>Fonte</h3>
-
- <p>
- O fonte desse manual está diponível em um repositório <a
-href="http://git.or.cz/">Git</a> em live.debian.net.
- </p>
-
- <ul>
- <li>Navegue: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Aviso legal</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/pt_BR/live-manual.ssm b/manual/pt_BR/live-manual.ssm
deleted file mode 100644
index f8faa5e..0000000
--- a/manual/pt_BR/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Debian Live Manual
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.<br><br>This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.<br><br>You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. <br><br>The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file.
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ About
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ User
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Project
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Examples
-
-<< user_examples.ssi
diff --git a/manual/pt_BR/project_bugs.ssi b/manual/pt_BR/project_bugs.ssi
deleted file mode 100644
index b0c34fc..0000000
--- a/manual/pt_BR/project_bugs.ssi
+++ /dev/null
@@ -1,198 +0,0 @@
-B~ Reporting bugs
-
-1~bugs Reporting bugs
-
-Debian Live is far from being perfect, but we want to make it as close as
-possible to perfect - with your help. Do not hesitate to report a bug: it is
-better to fill a report twice than never. However, this chapter includes
-recommendations how to file good bug reports.
-
-For the impatient:
-
-_* Always check first the image status updates on our homepage at
-http://live.debian.net/ for known issues.
-
-_* Always try to reproduce the bug with the *{most recent versions}* of
-live-build, live-boot, and live-config before submitting a bug report.
-
-_* Try to give *{as specific information as possible}* about the bug. This
-includes (at least) the version of live-build, live-boot, and live-config
-used and the distribution of the live system you are building.
-
-2~ Known issues
-
-Because Debian *{testing}* and Debian *{unstable}* distributions are a
-moving target, when you specify either as the target system distribution, a
-successful build may not always be possible.
-
-% FIXME:
-
-If this causes too much difficulty for you, do not build a system based on
-*{testing}* or *{unstable}*, but rather, use *{stable}*. live-build does
-always default to the *{stable}* release.
-
-Currently known issues are listed under the section 'status' on our homepage
-at http://live.debian.net/.
-
-It is out of the scope of this manual to train you to correctly identify and
-fix problems in packages of the development distributions, however, there
-are two things you can always try: If a build fails when the target
-distribution is *{testing}*, try *{unstable}*. If *{unstable}* does not work
-either, revert to *{testing}* and pin the newer version of the failing
-package from *{unstable}* (see {APT pinning}#apt-pinning for details).
-
-2~ Rebuild from scratch
-
-To ensure that a particular bug is not caused by an uncleanly built system,
-please always rebuild the whole live system from scratch to see if the bug
-is reproducible.
-
-2~ Use up-to-date packages
-
-Using outdated packages can cause significant problems when trying to
-reproduce (and ultimately fix) your problem. Make sure your build system is
-up-to-date and any packages included in your image are up-to-date as well.
-
-2~collect-information Collect information
-
-Please provide enough information with your report. At least include the
-exact version of live-build version where the bug is encountered and steps
-to reproduce it. Please use common sense and include other relevant
-information if you think that it might help in solving the problem.
-
-To make the most out of your bug report, we require at least the following
-information:
-
-_* Architecture of the host system
-
-_* Version of live-build on the host system
-
-_* Version of live-boot on the live system
-
-_* Version of live-config on the live system
-
-_* Version of #{debootstrap}# and/or #{cdebootstrap}# on the host system
-
-_* Architecture of the live system
-
-_* Distribution of the live system
-
-_* Version of the kernel on the live system
-
-You can generate a log of the build process by using the #{tee}# command. We
-recommend doing this automatically with an #{auto/build}# script; (see
-{Managing a configuration}#managing-a-configuration for details).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-At boot time, live-boot stores a log in #{/var/log/live.log}# (or
-#{/var/log/live-boot.log}#).
-
-Additionally, to rule out other errors, it is always a good idea to tar up
-your #{config/}# directory and upload it somewhere (do *{not}* send it as an
-attachment to the mailing list), so that we can try to reproduce the errors
-you encountered. If this is difficult (e.g. due to size) you can use the
-output of #{lb config --dump}# which produces a summary of your config tree
-(i.e. lists files in subdirectories of #{config/}# but does not include
-them).
-
-Remember to send in any logs that were produced with English locale
-settings, e.g. run your live-build commands with a leading #{LC_ALL=C}# or
-#{LC_ALL=en_US}#.
-
-2~ Isolate the failing case if possible
-
-If possible, isolate the failing case to the smallest possible change that
-breaks. It is not always easy to do this, so if you can't manage it for your
-report, don't worry. However, if you plan your development cycle well, using
-small enough change sets per iteration, you may be able to isolate the
-problem by constructing a simpler 'base' configuration that closely matches
-your actual configuration plus just the broken change set added to it. If
-you have a hard time sorting out which of your changes broke, it may be that
-you are including too much in each change set and should develop in smaller
-increments.
-
-2~ Use the correct package to report the bug against
-
-Where does the bug appear?
-
-3~ At build time whilst bootstrapping
-
-live-build first bootstraps a basic Debian system with #{debootstrap}# or
-#{cdebootstrap}#. Depending on the bootstrapping tool used and the Debian
-distribution it is bootstrapping, it may fail. If a bug appears here, check
-if the error is related to a specific Debian package (most likely), or if it
-is related to bootstrapping tool itself.
-
-In both cases, this is not a bug in Debian Live, but rather in Debian itself
-which we can not fix this directly. Please report such a bug against the
-bootstrapping tool or the failing package.
-
-3~ At build time whilst installing packages
-
-live-build installs additional packages from the Debian archive and
-depending on the Debian distribution used and the daily archive state, it
-can fail. If a bug appears here, check if the error is also reproducible on
-a normal system.
-
-If this is the case, this is not a bug in Debian Live, but rather in Debian
-- please report it against the failing package. Running #{debootstrap}#
-separately from the Live system build or running #{lb bootstrap --debug}#
-will give you more information.
-
-Also, if you are using a local mirror and/or any of sort of proxy and you
-are experiencing a problem, please always reproduce it first by
-bootstrapping from an official mirror.
-
-3~ At boot time
-
-If your image does not boot, please report it to the mailing list together
-with the information requested in {Collect
-information}#collect-information. Do not forget to mention, how/when the
-image failed, in Qemu, Virtualbox, VMWare or real hardware. If you are using
-a virtualization technology of any kind, please always run it on real
-hardware before reporting a bug. Providing a screenshot of the failure is
-also very helpful.
-
-3~ At run time
-
-If a package was successfully installed, but fails while actually running
-the Live system, this is probably a bug in Debian Live. However,
-
-2~ Do the research
-
-Before filing the bug, please search the web for the particular error
-message or symptom you are getting. As it is highly unlikely that you are
-the only person experiencing a particular problem, there is always a chance
-that it has been discussed elsewhere, and a possible solution, patch, or
-workaround has been proposed.
-
-You should pay particular attention to the Debian Live mailing list, as well
-as the homepage, as these are likely to contain the most up-to-date
-information. If such information exists, always include the references to it
-in your bug report.
-
-In addition, you should check the current bug lists for live-build,
-live-boot, and live-config to see whether something similar has been
-reported already.
-
-2~ Where to report bugs
-
-The Debian Live project keeps track of all bugs in the Debian Bug Tracking
-System (BTS). For information on how to use the system, please see
-http://bugs.debian.org/. You can also submit the bugs by using the
-#{reportbug}# command from the package with the same name.
-
-In general, you should report build time errors against the live-build
-package, boot time errors against live-boot, and run time errors against
-live-config. If you are unsure of which package is appropriate or need more
-help before submitting a bug report, please send a message to the mailing
-list and we will help you to figure it out.
-
-Please note that bugs found in distributions derived from Debian (such as
-Ubuntu and others) should *{not}* be reported to the Debian BTS unless they
-can be also reproduced on a Debian system using official Debian packages.
diff --git a/manual/pt_BR/project_coding-style.ssi b/manual/pt_BR/project_coding-style.ssi
deleted file mode 100644
index c4a9b86..0000000
--- a/manual/pt_BR/project_coding-style.ssi
+++ /dev/null
@@ -1,144 +0,0 @@
-B~ Coding Style
-
-1~coding-style Coding Style
-
-This chapter documents the coding style used in live-boot and others.
-
-2~ Compatibility
-
-_* Don't use syntax or semantics that are unique to the Bash shell. For
-example, the use of array constructs.
-
-_* Only use the POSIX subset - for example, use $(foo) over `foo`.
-
-_* You can check your scripts with 'sh -n' and 'checkbashisms'.
-
-2~ Indenting
-
-_* Always use tabs over spaces.
-
-2~ Wrapping
-
-_* Generally, lines are 80 chars at maximum.
-
-_* Use the "Linux style" of line breaks:
-
-Bad:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Good:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* The same holds for functions:
-
-Bad:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Good:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variables
-
-_* Variables are always in capital letters.
-
-_* Variables that used in #{lb config}# always start with #{LB_}# prefix.
-
-_* Internal temporary variables in live-build should start with the
-#{\_LB_}# prefix.
-
-_* Local variables start with live-build #{\_\_LB_}# prefix.
-
-_* Variables in connection to a boot parameter in live-config start with
-#{LIVE_}#.
-
-_* All other variables in live-config start with #{_}# prefix.
-
-_* Use braces around variables; e.g. write #{${FOO}}# instead of #{$FOO}#.
-
-_* Always protect variables with quotes to respect potential whitespaces:
-write #{"${FOO}"}# not #{${FOO}}#.
-
-_* For consistency reasons, always use quotes when assigning values to
-variables:
-
-Bad:
-
-code{
-
- FOO=bar
-
-}code
-
-Good:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* If multiple variables are used, quote the full expression:
-
-Bad:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Good:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Miscellaneous
-
-_* Use "#{|}#" (without the surround quotes) as a seperator in calls to sed,
-e.g. "#{sed -e 's|foo|bar|'}#" (without "").
-
-_* Don't use the #{test}# command for comparisons or tests, use "#{[}#"
-"#{]}#" (without ""); e.g. "#{if [ -x /bin/foo ]; ...}#" and not "#{if test
--x /bin/foo; ...}#".
-
-_* Use #{case}# wherever possible over #{test}#, as it's easier to read and
-faster in execution.
diff --git a/manual/pt_BR/project_procedures.ssi b/manual/pt_BR/project_procedures.ssi
deleted file mode 100644
index fb4ede8..0000000
--- a/manual/pt_BR/project_procedures.ssi
+++ /dev/null
@@ -1,139 +0,0 @@
-B~ Procedures
-
-1~procedures Procedures
-
-This chapter documents the procedures within the Debian Live project for
-various tasks that need cooperation with other teams in Debian.
-
-2~ Udeb Uploads
-
-Before commiting releases of a udeb in d-i svn, one has to call:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Major Releases
-
-Releasing a new stable major version of Debian includes a lot of different
-teams working together to make it happen. At some point, the Live team comes
-in and builds live system images. The requirements to do this are:
-
-_* A mirror containing the released versions for the debian, debian-security
-and debian-volatile archive which the debian-live buildd can access.
-
-_* The names of the image need to be known
-(e.g. debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* The packagelists need to have been updated.
-
-_* The data from debian-cd needs to be synced (udeb exclude lists).
-
-_* The includes from debian-cd needs to be synced (README.*, doc/*, etc.).
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-2~ Point Releases
-
-_* Again, we need updated mirror of debian, debian-security and
-debian-volatile.
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-_* Send announcement mail.
-
-3~ Point release announcement template
-
-An annoucement mail for point releases can be generated using the template
-below and the following command:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-Please check the mail carefully before sending and pass it to others for
-proof-reading.
-
-code{
-
- Debian Live images for Debian GNU/Linux %major% updated
-
- The Debian Live project is pleased to announce the availability of
- updated Live images for its stable distribution Debian GNU/Linux %major%
- (codename "%codename%").
-
- The images are available for download at:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- This update incorporates the changes made in the %minor% point release,
- which adds corrections for security problems to the stable release
- along with a few adjustments for serious problems. A full list of the
- changes may be viewed at:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
- It also includes the following Live-specific changes:
-
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
-
-
- URLs
- ----
-
- Download location of updated images:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Projeto Debian Live Homepage:
-
- <http://live.debian.net/>
-
- The current stable distribution:
-
- <http://ftp.debian.org/debian/dists/stable>
-
- stable distribution information (release notes, errata etc.):
-
- <http://www.debian.org/releases/stable/>
-
- Security announcements and information:
-
- <http://www.debian.org/security/>
-
-
- About Debian
- -------------
-
- The Debian Project is an association of Free Software developers who
- volunteer their time and effort in order to produce the completely free
- operating system Debian GNU/Linux.
-
-
- About Debian Live
- -----------------
-
- Debian Live is an official sub-project of Debian which produces Debian
- systems that do not require a classical installer. Images are available
- for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
- filesystem images for booting directly from the internet.
-
-
- Contact Information
- -------------------
-
- For further information, please visit the Debian Live web pages at
- <http://live.debian.net/> or alternatively send mail to
- <debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/pt_BR/user_basics.ssi b/manual/pt_BR/user_basics.ssi
deleted file mode 100644
index 4429660..0000000
--- a/manual/pt_BR/user_basics.ssi
+++ /dev/null
@@ -1,528 +0,0 @@
-:B~ The basics
-
-1~the-basics The basics
-
-This chapter contains a brief overview of the build process and instructions
-for using the three most commonly used image types. The most versatile image
-type, #{iso-hybrid}#, may be used on a virtual machine, optical media or USB
-portable storage device. In certain special cases, such as the use of
-persistence, #{usb-hdd}# may be more suitable for USB devices. The chapter
-finishes with instructions for building and using a #{net}# type image,
-which is a bit more involved due to the setup required on the server. This
-is a slightly advanced topic for anyone who is not familiar already with
-netbooting, but is included here because once the setup is done, it is a
-very convenient way to test and deploy images for booting on the local
-network without the hassle of dealing with image media.
-
-Throughout the chapter, we will often refer to the default filenames
-produced by live-build. If you are downloading a prebuilt image instead, the
-actual filenames may vary.
-
-2~what-is-live What is a live system?
-
-A live system usually means an operating system booted on a computer from a
-removable medium, such as a CD-ROM or USB stick, or from a network, ready to
-use without any installation on the usual drive(s), with auto-configuration
-done at run time (see {Terms}#terms).
-
-With Debian Live, it's a Debian GNU/Linux operating system, built for one of
-the supported architectures (currently amd64, i386, powerpc and sparc). It
-is made from the following parts:
-
-_* *{Linux kernel image}*, usually named #{vmlinuz*}#
-
-_* *{Initial RAM disk image (initrd)}*: a RAM disk set up for the Linux
-boot, containing modules possibly needed to mount the System image and some
-scripts to do it.
-
-_* *{System image}*: The operating system's filesystem image. Usually, a
-SquashFS compressed filesystem is used to minimize the Debian Live image
-size. Note that it is read-only. So, during boot the Debian Live system will
-use a RAM disk and 'union' mechanism to enable writing files within the
-running system. However, all modifications will be lost upon shutdown unless
-optional persistence is used (see {Persistence}#persistence).
-
-_* *{Bootloader}*: A small piece of code crafted to boot from the chosen
-media, possibly presenting a prompt or menu to allow selection of
-options/configuration. It loads the Linux kernel and its initrd to run with
-an associated system filesystem. Different solutions can be used, depending
-on the target media and format of the filesystem containing the previously
-mentioned components: isolinux to boot from a CD or DVD in ISO9660 format,
-syslinux for HDD or USB drive booting from a VFAT partition, extlinux for
-ext2/3/4 and btrfs partitions, pxelinux for PXE netboot, GRUB for ext2/3/4
-partitions, etc.
-
-You can use live-build to build the system image from your specifications,
-set up a Linux kernel, its initrd, and a bootloader to run them, all in one
-media-dependant format (ISO9660 image, disk image, etc.).
-
-2~building-iso-hybrid First steps: building an ISO hybrid image
-
-Regardless of the image type, you will need to perform the same basic steps
-to build an image each time. As a first example, execute the following
-sequence of live-build commands to create a basic ISO hybrid image
-containing just the Debian standard system without X.org. It is suitable for
-burning to CD or DVD media, and also to copy onto a USB stick.
-
-First, run the #{lb config}# command. This will create a "config/" hierarchy
-in the current directory for use by other commands:
-
-code{
-
- $ lb config
-
-}code
-
-No parameters are passed to #{lb config}#, so defaults for all of its
-various options will be used. See {The lb config command}#lb-config for more
-details.
-
-Now that the "config/" hierarchy exists, build the image with the #{lb
-build}# command:
-
-code{
-
- # lb build
-
-}code
-
-This process can take a while, depending on the speed of your network
-connection. When it is complete, there should be a #{binary-hybrid.iso}#
-image file, ready to use, in the current directory.
-
-2~using-iso-hybrid Using an ISO hybrid live image
-
-After either building or downloading an ISO hybrid image, which can be
-obtained at http://www.debian.org/CD/live/, the usual next step is to
-prepare your media for booting, either CD-R(W) or DVD-R(W) optical media or
-a USB stick.
-
-3~burning-iso-image Burning an ISO image to a physical medium
-
-Burning an ISO image is easy. Just install wodim and use it from the
-command-line to burn the image. For instance:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copying an ISO hybrid image to a USB stick
-
-ISO images prepared with the #{isohybrid}# command, like the images produced
-by the default #{iso-hybrid}# binary image type, can be simply copied to a
-USB stick with the #{dd}# program or an equivalent. Plug in a USB stick with
-a size large enough for your image file and determine which device it is,
-which we hereafter refer to as #{${USBSTICK}}#. This is the device file of
-your key, such as #{/dev/sdb}#, not a partition, such as #{/dev/sdb1}#! You
-can find the right device name by looking in #{dmesg}#'s output after
-plugging in the stick, or better yet, #{ls -l /dev/disk/by-id}#.
-
-Once you are certain you have the correct device name, use the #{dd}#
-command to copy the image to the stick. *{This will definitely overwrite
-any previous contents on your stick!}*
-
-code{
-
- $ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Booting the live media
-
-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.
-
-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.
-
-2~using-virtual-machine Using a virtual machine for testing
-
-It can be a great time-saver for the development of live images to run them
-in a virtual machine (VM). This is not without its caveats:
-
-_* Running a VM requires enough RAM for both the guest OS and the host and a
-CPU with hardware support for virtualization is recommended.
-
-_* There are some inherent limitations to running on a VM, e.g. poor video
-performance, limited choice of emulated hardware.
-
-_* When developing for specific hardware, there is no substitute for running
-on the hardware itself.
-
-_* Occasionally there are bugs that relate only to running in a VM. When in
-doubt, test your image directly on the hardware.
-
-Provided you can work within these constraints, survey the available VM
-software and choose one that is suitable for your needs.
-
-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.
-
-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{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Booting an ISO image is simple:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-See the man pages for more details.
-
-3~testing-iso-with-virtualbox Testing an ISO image with virtualbox-ose
-
-In order to test the ISO with #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Create a new virtual machine, change the storage settings to use
-#{binary-hybrid.iso}# as the CD/DVD device, and start the machine.
-
-Note: For live systems containing X.org that you want to test with
-#{virtualbox-ose}#, you may wish to include the VirtualBox X.org driver
-package, #{virtualbox-ose-guest-x11}#, in your live-build
-configuration. Otherwise, the resolution is limited to 800x600.
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Building a USB/HDD image
-
-Building a USB/HDD image is similar to ISO hybrid in all respects except you
-specify #{-b usb-hdd}# and the resulting filename is #{binary.img}# which
-cannot be burnt to optical media. It is suitable for booting from USB
-sticks, USB hard drives, and various other portable storage
-devices. Normally, an ISO hybrid image can be used for this purpose instead,
-but if you have a BIOS which does not handle hybrid images properly, or want
-to use the remaining space on the media for some purpose, such as a
-persistence partition, you need a USB/HDD image.
-
-Note: if you created an ISO hybrid image with the previous example, you will
-need to clean up your working directory with the #{lb clean}# command (see
-{The lb clean command}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as before, except this time specifying the
-USB/HDD image type:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-When the build finishes, a #{binary.img}# file should be present in the
-current directory.
-
-2~using-usb-hdd-image Using a USB/HDD image
-
-The generated binary image contains a VFAT partition and the syslinux
-bootloader, ready to be directly written on a USB stick. Since using a
-USB/HDD image is just like using an ISO hybrid image on USB, follow the
-instructions in {Using an ISO hybrid live image}#using-iso-hybrid, except
-use the filename #{binary.img}# instead of #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Testing a USB/HDD image with Qemu
-
-First, install QEMU as described above in {Testing an ISO image with
-QEMU}#testing-iso-with-qemu. Then run #{kvm}# or #{qemu}#, depending on
-which version your host system needs, specifying #{binary.img}# as the first
-hard drive.
-
-code{
-
- $ kvm -hda binary.img
-
-}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.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-After the partition is created, where #{${PARTITION}}# is the name of the
-partition, such as #{/dev/sdb2}#, you have to create a filesystem on it. One
-possible choice would be ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Note: If you want to use the extra space with Windows, apparently that OS
-cannot normally access any partitions but the first. Some solutions to this
-problem have been discussed on our {mailing list}#contact, but it seems
-there are no easy answers.
-
-*{Remember: Every time you install a new binary.img on the stick, all data on the stick will be lost because the partition table is overwritten by the contents of the image, so back up your extra partition first to restore again after updating the live image.}*
-
-2~building-netboot-image Building a netboot image
-
-The following sequence of commands will create a basic netboot image
-containing the Debian standard system without X.org. It is suitable for
-booting over the network.
-
-Note: if you performed any previous examples, you will need to clean up your
-working directory with the #{lb clean}# command:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as follows to configure your image for
-netbooting:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-In contrast with the ISO and USB/HDD images, netbooting does not, itself,
-serve the filesystem image to the client, so the files must be served via
-NFS. The #{--net-root-path}# and #{--net-root-server}# options specify the
-location and server, respectively, of the NFS server where the filesytem
-image will be located at boot time. Make sure these are set to suitable
-values for your network and server.
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-In a network boot, the client runs a small piece of software which usually
-resides on the EPROM of the Ethernet card. This program sends a DHCP request
-to get an IP address and information about what to do next. Typically, the
-next step is getting a higher level bootloader via the TFTP protocol. That
-could be pxelinux, GRUB, or even boot directly to an operating system like
-Linux.
-
-For example, if you unpack the generated #{binary-net.tar.gz}# archive in
-the #{/srv/debian-live}# directory, you'll find the filesystem image in
-#{live/filesystem.squashfs}# and the kernel, initrd and pxelinux bootloader
-in #{tftpboot/debian-live/i386}#.
-
-We must now configure three services on the server to enable netboot: the
-DHCP server, the TFTP server and the NFS server.
-
-3~ DHCP server
-
-We must configure our network's DHCP server to be sure to give an IP address
-to the netbooting client system, and to advertise the location of the PXE
-bootloader.
-
-Here is an example for inspiration, written for the ISC DHCP server
-#{isc-dhcp-server}# in the #{/etc/dhcp/dhcpd.conf}# configuration file:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ TFTP server
-
-This serves the kernel and initial ramdisk to the system at run time.
-
-You should install the tftpd-hpa package. It can serve all files contained
-inside a root directory, usually #{/srv/tftp}#. To let it serve files inside
-#{/srv/debian-live/tftpboot}#, run as root the following command:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-and fill in the new tftp server directory when being asked about it.
-
-3~ NFS server
-
-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.
-
-Then, make the filesystem image available through NFS by adding a line like
-the following to #{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-and tell the NFS server about this new export with the following command:
-
-code{
-
- # exportfs -rv
-
-}code
-
-Setting up these three services can be a little tricky. You might need some
-patience to get all of them working together. For more information, see the
-syslinux wiki at http://syslinux.zytor.com/wiki/index.php/PXELINUX or the
-Debian Installer Manual's TFTP Net Booting section at
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. They might help,
-as their processes are very similar.
-
-3~ Netboot testing HowTo
-
-Netboot image creation is made easy with live-build magic, but testing the
-images on physical machines can be really time consuming.
-
-To make our life easier, we can use virtualization. There are two solutions.
-
-3~ Qemu
-
-_* Install #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Edit #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Get, or build a #{grub-floppy-netboot}# (in the svn).
-
-Launch #{qemu}# with "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Install VMWare Player ("free as in beer" edition)
-
-_* Create a PXETester directory, and create a text file called #{pxe.vwx}#
-inside
-
-_* Paste this text inside:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* You can play with this configuration file (e.g. change memory limit to
-256)
-
-_* Double click on this file (or run VMWare player and select this file).
-
-_* When running just press space if that strange question comes up...
diff --git a/manual/pt_BR/user_customization-binary.ssi b/manual/pt_BR/user_customization-binary.ssi
deleted file mode 100644
index 6f843f8..0000000
--- a/manual/pt_BR/user_customization-binary.ssi
+++ /dev/null
@@ -1,35 +0,0 @@
-B~ Customizing the binary image
-
-1~customizing-binary Customizing the binary image
-
-2~ Bootloader
-
-live-build uses syslinux as bootloader by default, which is by default
-configured to pause indefinitely at its splash screen. To adjust this, you
-can pass #{--syslinux-timeout TIMEOUT}# to #{lb config}#. The value is
-specified in units of seconds. A timeout of 0 (zero) disables the timeout
-completely. For more information please see syslinux(1).
-
-2~ ISO metadata
-
-When creating an ISO9660 binary image, you can use the following options to
-add various textual metadata for your image. This can help you easily
-identify the version or configuration of an image without booting it.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: This should describe the
-application that will be on the image. The maximum length for this field is
-128 characters.
-
-_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: This should describe the
-preparer of the image, usually with some contact details. The default for
-this option is the live-build version you are using, which may help with
-debugging later. The maximum length for this field is 128 characters.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: This should describe the
-publisher of the image, usually with some contact details. The maximum
-length for this field is 128 characters.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: This should specify the volume ID of
-the image. This is used as a user-visible label on some platforms such as
-Windows and Apple Mac OS. The maximum length for this field is 32
-characters.
diff --git a/manual/pt_BR/user_customization-contents.ssi b/manual/pt_BR/user_customization-contents.ssi
deleted file mode 100644
index 814ba40..0000000
--- a/manual/pt_BR/user_customization-contents.ssi
+++ /dev/null
@@ -1,154 +0,0 @@
-:B~ Customizing contents
-
-1~customizing-contents Customizing contents
-
-This chapter discusses fine-tuning customization of the live system contents
-beyond merely choosing which packages to include. Includes allow you to add
-or replace arbitrary files in your Debian Live image, hooks allow you to
-execute arbitrary commands at different stages of the build and at boot
-time, and preseeding allows you to configure packages when they are
-installed by supplying answers to debconf questions.
-
-2~ Includes
-
-While ideally a Debian live system would include files entirely provided by
-unmodified Debian packages, it is sometimes convenient to provide or modify
-some content by means of files. Using includes, it is possible to add (or
-replace) arbitrary files in your Debian Live image. live-build provides
-three mechanisms for using them:
-
-_* Chroot local includes: These allow you to add or replace files to the
-chroot/Live filesystem. Please see {Live/chroot local
-includes}#live-chroot-local-includes for more information.
-
-_* Binary local includes: These allow you to add or replace files in the
-binary image. Please see {Binary local includes}#binary-local-includes for
-more information.
-
-_* Binary includes: These allow you to add or replace Debian specific files
-in the binary image, such as the templates and tools directories. Please see
-{Binary includes}#binary-includes for more information.
-
-Please see {Terms}#terms for more information about the distinction between
-the "Live" and "binary" images.
-
-3~live-chroot-local-includes Live/chroot local includes
-
-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/chroot_local-includes}#
-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{
-
- $ mkdir -p config/chroot_local-includes/var/www
- $ cp /path/to/my/index.html config/chroot_local-includes/var/www
-
-}code
-
-Your configuration will then have the following layout:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Chroot local includes are installed after package installation so that files
-installed by packages are overwritten.
-
-3~binary-local-includes Binary local includes
-
-To include material such as documentation or videos on the media filesystem
-so that it is accessible immediately upon insertion of the media without
-booting the Live system, you can use binary local includes. This works in a
-similar fashion to chroot local includes. For example, suppose the files
-#{~/video_demo.*}# are demo videos of the live system described by and
-linked to by an HTML index page. Simply copy the material to
-#{config/binary_local-includes/}# as follows:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-These files will now appear in the root directory of the live media.
-
-3~binary-includes Binary includes
-
-live-build has some standard files (like documentation) that gets included
-in the default configuration on every live media. This can be disabled with:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-Otherwise, the material will be installed by live-build in #{/includes/}# by
-default on the media filesystem, or else you can specify an alternate path
-with #{--includes}#.
-
-2~ Hooks
-
-Hooks allow commands to be performed in the chroot and binary stages of the
-build in order to customize the image.
-
-3~live-chroot-local-hooks Live/chroot local hooks
-
-To run commands in the chroot stage, create a hook script containing the
-commands in the #{config/chroot_local-hooks}# directory. The hook will run
-in the chroot after the rest of your chroot configuration has been applied,
-so remember to ensure your configuration includes all packages and files
-your hook needs in order to run. See the example chroot hook scripts for
-various common chroot customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-3~boot-time-hooks Boot-time hooks
-
-To execute commands at boot time, you can supply live-config hooks as
-explained in the "Customization" section of its man page. Examine
-live-config's own hooks provided in #{/lib/live/config/}#, noting the
-sequence numbers. Then provide your own hook prefixed with an appropriate
-sequence number, either as a chroot local include in
-#{config/chroot_local-includes/lib/live/config/}#, or as a custom package as
-discussed in {Installing modified or third-party
-packages}#installing-modified-or-third-party-packages.
-
-3~ Binary local hooks
-
-To run commands in the binary stage, create a hook script containing the
-commands in the #{config/binary_local-hooks}#. The hook will run after all
-other binary commands are run, but before binary_checksums, the very last
-binary commands The commands in your hook do not run in the chroot, so take
-care to not modify any files outside of the build tree, or you may damage
-your build system! See the example binary hook scripts for various common
-binary customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-2~ Preseeding Debconf questions
-
-Files in the #{config/chroot_local-preseed}# directory are considered to be
-debconf preseed files and are installed by live-build using
-#{debconf-set-selections}#.
-
-For more information about debconf, please see debconf(7) in the #{debconf}#
-package.
diff --git a/manual/pt_BR/user_customization-installer.ssi b/manual/pt_BR/user_customization-installer.ssi
deleted file mode 100644
index 9349f27..0000000
--- a/manual/pt_BR/user_customization-installer.ssi
+++ /dev/null
@@ -1,88 +0,0 @@
-:B~ Customizing Debian Installer
-
-1~customizing-installer Customizing Debian Installer
-
-Debian Live system images can be integrated with Debian Installer. There are
-a number of different types of installation, varying in what is included and
-how the installer operates.
-
-Please note the careful use of capital letters when referring to the "Debian
-Installer" in this section - when used like this we refer explicitly to the
-official installer for the Debian system, not anything else. It is often
-seen abbreviated to "d-i".
-
-2~ Types of Debian Installer
-
-The three main types of installer are:
-
-*{"Regular" Debian Installer}*: This is a normal Debian Live image with a seperate kernel and initrd which (when selected from the appropriate bootloader) launches into a standard Debian Installer instance, just as if you had downloaded a CD image of Debian and booted it. Images containing a live system and such an otherwise independent installer are often referred to as "combined images".
-
-On such images, Debian is installed by fetching and installing .deb packages
-using #{debootstrap}# or #{cdebootstrap}#, from the local media or some
-network-based network, resulting in a standard Debian system being installed
-to the hard disk.
-
-This whole process can be preseeded and customized in a number of ways; see
-the relevant pages in the Debian Installer manual for more information. Once
-you have a working preseeding file, live-build can automatically put it in
-the image and enable it for you.
-
-*{"Live" Debian Installer}*: This is a Debian Live image with a separate kernel and initrd which (when selected from the appropriate bootloader) launches into an instance of the Debian Installer.
-
-Installation will proceed in an identical fashion to the "Regular"
-installation described above, but at the actual package installation stage,
-instead of using #{debootstrap}# to fetch and install packages, the live
-filesystem image is copied to the target. This is achieved with a special
-udeb called live-installer.
-
-After this stage, the Debian Installer continues as normal, installing and
-configuring items such as bootloaders and local users, etc.
-
-Note: to support both normal and live installer entries in the bootloader of
-the same live media, you must disable live-installer by preseeding
-#{live-installer/enable=false}#.
-
-*{"Desktop" Debian Installer}*: Regardless of the type of Debian Installer included, #{d-i}# can be launched from the Desktop by clicking on an icon. This is user friendlier in some situations. In order to make use of this, the debian-installer-launcher package needs to be included.
-
-Note that by default, live-build does not include Debian Installer images in
-the images, it needs to be specifically enabled with #{lb config}#. Also,
-please note that for the "Desktop" installer to work, the kernel of the live
-system must match the kernel #{d-i}# uses for the specified
-architecture. For example:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Customizing Debian Installer by preseeding
-
-As described in the Debian Installer Manual, Appendix B at
-http://www.debian.org/releases/stable/i386/apb.html, "Preseeding provides a
-way to set answers to questions asked during the installation process,
-without having to manually enter the answers while the installation is
-running. This makes it possible to fully automate most types of installation
-and even offers some features not available during normal installations."
-This kind of customization is best accomplished with live-build by placing
-the configuration in a #{preseed.cfg}# file included in
-#{config/binary_debian-installer/}#. For example, to preseed setting the
-locale to #{en_US}#:
-
-code{
-
- $ echo "d-i debian-installer/locale string en_US" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Customizing Debian Installer content
-
-For experimental or debugging purposes, you might want to include locally
-built #{d-i}# component udeb packages. Place these in
-#{config/binary_local-udebs/}# to include them in the image. Additional or
-replacement files and directories may be included in the installer initrd as
-well, in a similar fashion to {Live/chroot local
-includes}#live-chroot-local-includes, by placing the material in
-#{config/binary_debian-installer-includes/}#.
diff --git a/manual/pt_BR/user_customization-overview.ssi b/manual/pt_BR/user_customization-overview.ssi
deleted file mode 100644
index 137e322..0000000
--- a/manual/pt_BR/user_customization-overview.ssi
+++ /dev/null
@@ -1,76 +0,0 @@
-:B~ Customizing contents
-
-1~customization-overview Customization overview
-
-This chapter gives an overview of the various ways in which you may
-customize a Debian Live system.
-
-2~ Build time vs. boot time configuration
-
-Live system configuration options are divided into build-time options which
-are options that are applied at build time and boot-time options which are
-applied at boot time. Boot-time options are further divided into those
-occurring early in the boot, applied by the live-boot package, and those
-that happen later in the boot, applied by live-config. Any boot-time option
-may be modified by the user by specifying it at the boot prompt. The image
-may also be built with default boot parameters so users can normally just
-boot directly to the live system without specifying any options when all of
-the defaults are suitable. In particular, the argument to #{lb
---bootappend-live}# consists of any default kernel command line options for
-the Live system, such as persistence, keyboard layouts, or timezone. See
-{Customizing locale and language}#customizing-locale-and-language, for
-example.
-
-Build-time configuration options are described in the #{lb config}# man
-page. Boot-time options are described in the man pages for live-boot and
-live-config. Although the live-boot and live-config packages are installed
-within the live system you are building, it is recommended that you also
-install them on your build system for easy reference when you are working on
-your configuration. It is safe to do so, as none of the scripts contained
-within them are executed unless the system is configured as a live system.
-
-2~stages-of-the-build Stages of the build
-
-The build process is divided into stages, with various customizations
-applied in sequence in each. The first stage to run is the *{bootstrap}*
-stage. This is the initial phase of populating the chroot directory with
-packages to make a barebones Debian system. This is followed by the
-*{chroot}* stage, which completes the construction of chroot directory,
-populating it with all of the packages listed in the configuration, along
-with any other materials. Most customization of content occurs in this
-stage. The final stage of preparing the live image is the *{binary}* stage,
-which builds a bootable image, using the contents of the chroot directory to
-construct the root filesystem for the Live system, and including the
-installer and any other additional material on the target media outside of
-the Live system's filesystem. After the live image is built, if enabled, the
-source tarball is built in the *{source}* stage.
-
-Within each of these stages, there is a particular sequence in which
-commands are applied. These are arranged in such a way as to ensure
-customizations can be layered in a reasonable fashion. For example, within
-the *{chroot}* stage, preseeds are applied before any packages are
-installed, packages are installed before any locally included files or
-patches are applied, and hooks are run later, after all of the materials are
-in place.
-
-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.
-
-2~ Customization tasks
-
-The following chapters are organized by the kinds of customization task
-users typically perform: {Customizing package
-installation}#customizing-package-installation, {Customizing
-contents}#customizing-contents and {Customizing locale and
-language}#customizing-locale-and-language cover just a few of the things you
-might want to do.
diff --git a/manual/pt_BR/user_customization-packages.ssi b/manual/pt_BR/user_customization-packages.ssi
deleted file mode 100644
index 6b6f4fa..0000000
--- a/manual/pt_BR/user_customization-packages.ssi
+++ /dev/null
@@ -1,586 +0,0 @@
-:B~ Customizing package installation
-
-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.
-
-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 #{squeeze}# for the Squeeze 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{
-
- $ lb config --distribution sid
-
-}code
-
-Within the distribution archive, archive areas are major divisions of the
-archive. In Debian, these are #{main}#, #{contrib}# and #{non-free}#. Only
-#{main}# contains software that is part of the Debian distribution, hence
-that is the default. One or more values may be specified, e.g.
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Experimental support is available for some Debian derivatives through a
-#{--mode}# option. By default, this option is set to #{debian}#, even if you
-are building on a non-Debian system. If you specify #{--mode ubuntu}# or
-#{--mode emdebian}#, the distribution names and archive areas for the
-specified derivative are supported instead of the ones for Debian. The mode
-also modifies live-build behaviour to suit the derivatives.
-
-*{Note:}* The projects for whom these modes were added are primarily responsible for supporting users of these options. The Debian live project, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
-
-3~ Distribution mirrors
-
-The Debian archive is replicated across a large network of mirrors around
-the world so that people in each region can choose a nearby mirror for best
-download speed. Each of the #{--mirror-*}# options governs which
-distribution mirror is used at various stages of the build. Recall from
-{Stages of the build}#stages-of-the-build that the *bootstrap* stage is when
-the chroot is initially populated by debootstrap with a minimal system, and
-the *chroot* stage is when the chroot used to construct the live system's
-filesystem is built. Thus, the corresponding mirror switches are used for
-those stages, and later, in the *binary* stage, the #{--mirror-binary}# and
-#{--mirror-binary-security}# values are used, superceding any mirrors used
-in an earlier stage.
-
-3~distribution-mirrors-build-time Distribution mirrors used at build time
-
-To set the distribution mirrors used at build time to point at a local
-mirror, it is sufficient to set #{--mirror-bootstrap}# and
-#{--mirror-chroot-security}# as follows.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-The chroot mirror, specified by #{--mirror-chroot}#, defaults to the
-#{--mirror-bootstrap}# value.
-
-3~ Distribution mirrors used at run time
-
-The #{--mirror-binary*}# options govern the distribution mirrors placed in
-the binary image. These may be used to install additional packages while
-running the live system. The defaults employ #{cdn.debian.net}#, a service
-that chooses a geographically close mirror based on the user's IP
-number. This is a suitable choice when you cannot predict which mirror will
-be best for all of your users. Or you may specify your own values as shown
-in the example below. An image built from this configuration would only be
-suitable for users on a network where "#{mirror}#" is reachable.
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Additional repositories
-
-You may add more repositories, broadening your package choices beyond what
-is available in your target distribution. These may be, for example, for
-backports, experimental or custom packages. To configure additional
-repositories, create #{config/chroot_sources/your-repository.chroot}#,
-and/or #{config/chroot_sources/your-repository.binary}# files. As with the
-#{--mirror-*}# options, these govern the repositories used in the *chroot*
-stage when building the image, and in the *binary* stage, i.e. for use when
-running the live system.
-
-For example, #{config/chroot_sources/live.chroot}# allows you to install
-packages from the debian live snapshot repository at live system build time.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-If you add the same line to #{config/chroot_sources/live.binary}#, the
-repository will be added to your live system's #{/etc/apt/sources.list.d/}#
-directory.
-
-If such files exist, they will be picked up automatically.
-
-You should also put the GPG key used to sign the repository into
-#{config/chroot_sources/your-repository.{binary,chroot}.gpg}# files.
-
-*{Note:}* some preconfigured package repositories are available for easy selection through the #{--repository}# option, e.g. for enabling live snapshots, a simple command is enough to enable it:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Choosing packages to install
-
-There are a number of ways to choose which packages live-build will install
-in your image, covering a variety of different needs. You can simply name
-individual packages to install, either with the #{--packages}# option for a
-few packages, or in a package list of your own for larger numbers. You can
-also choose larger predefined lists of packages, or use APT tasks. And
-finally, you may place package files in your #{config/}# tree, which is well
-suited to testing of new or experimental packages before they are available
-from a repository.
-
-3~ Choosing a few packages
-
-When the number of packages added is small, simply specify
-#{--packages}#. For example:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-The behaviour of live-build when specifying a package that does not exist is
-determined by your choice of APT utility. See {Choosing apt or
-aptitude}#choosing-apt-or-aptitude for more details.
-
-If you need to specify a large number of packages to be installed or you
-need flexibility regarding which packages to install, use package lists as
-discussed in the following section, {Package lists}#package-lists.
-
-3~package-lists Package lists
-
-Package lists are a powerful way of expressing which packages should be
-installed. The list syntax supports included files and conditional sections
-which makes it easy to build lists from other lists and adapt them for use
-in multiple configurations. You can use predefined package lists, providing
-in a modular fashion package selections from each of the major desktop
-environments and some special purpose lists, as well as standard lists the
-others are based upon. You can also provide your own package lists, or use a
-combination of both.
-
-3~ Predefined package lists
-
-The simplest way to use lists is to specify one or more predefined lists
-with the #{--packages-lists}# option. For example:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-In addition to these lists, live-build supports four virtual package lists:
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#,
-each of which provide a more extensive selection of packages that
-corresponds with Debian Installer defaults for these desktop
-environments. See {Desktop and language tasks}#desktop-and-language-tasks
-for more details.
-
-*{Note:}* The prebuilt GNOME, KDE, LXDE and XFCE images available for download at http://live.debian.net are built using the corresponding virtual #{*-desktop}# lists.
-
-The default location for the list files on your system is
-#{/usr/share/live/build/lists/}#. To determine the packages in a given list,
-read the corresponding file, paying attention to included files and
-conditionals as described in the following sections.
-
-3~ Local package lists
-
-You may supplement or replace entirely the supplied lists using local
-package lists stored in #{config/chroot_local-packageslists/}#.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed. Local package lists always override package lists
-distributed with live-build. This can cause undesired effects, we therefore
-recommend to use unique names for local package lists.
-
-3~ Local binary package lists
-
-In case you want to include some required .deb packages to live media's
-#{pool/}# (without installing them onto the live image) you may need to use
-lists using binary local package lists stored in
-#{config/binary_local-packageslists/}#. Such media can be used as a
-customized Debian install image for offline installations.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed.
-
-3~ Extending a provided package list using includes
-
-The package lists that are included with live-build make extensive use of
-includes. Refer to these in the #{/usr/share/live/build/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/chroot_local-packageslists/mygnome.list}# with
-the following contents:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Using conditionals inside package lists
-
-Any of the live-build configuration variables stored in #{config/*}# (minus
-the #{LB_}# prefix) may be used in conditional statements in package
-lists. Generally, this means any #{lb config}# option uppercased and with
-dashes changed to underscores. But in practice, it is only the ones that
-influence package selection that make sense, such as #{DISTRIBUTION}#,
-#{ARCHITECTURE}# or #{ARCHIVE_AREAS}#.
-
-For example, to install #{ia32-libs}# if the #{--architecture amd64}# is
-specified:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-You may test for any one of a number of values, e.g. to install
-#{memtest86+}# if either #{--architecture i386}# or #{--architecture amd64}#
-is specified:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-You may also test against variables that may contain more than one value,
-e.g. to install #{vrms}# if either #{contrib}# or #{non-free}# is specified
-via #{--archive-areas}#:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-A conditional may surround an #{#include}# directive:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-The nesting of conditionals is not supported.
-
-3~ Tasks
-
-The Debian Installer offers the user choices of a number of preselected
-lists of packages, each one focused on a particular kind of system, or task
-a system may be used for, such as "Graphical desktop environment", "Mail
-server" or "Laptop". These lists are called "tasks" and are supported by APT
-through the "Task:" field. You can specify one or more tasks in live-build
-via the #{--tasks}# option, as in the example below.
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-The primary tasks available in the Debian Installer can be listed with
-#{tasksel --list-tasks}# in the live system. The contents of any task,
-including ones not included in this list, may be examined with #{tasksel
---task-packages}#.
-
-3~desktop-and-language-tasks Desktop and language tasks
-
-Desktop and language tasks are special cases. In the Debian Installer, if
-the medium was prepared for a particular desktop environment flavour, the
-corresponding task will be automatically installed. Thus, there are
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#
-tasks, none of which are offered in #{tasksel}#'s menu. Likewise, there are
-no menu entries for tasks for languages, but the user's language choice
-during the install influences the selection of corresponding language tasks.
-
-In live-build, therefore, these special cases are also given special
-consideration, but with three notable differences at the time of writing.
-
-First, there is no provision made yet automatically for language tasks,
-although a subset of those packages are included if you specify #{lb config
---language}#. If you need those tasks, which include such things as
-language-specific fonts and input-method packages, you need to specify them
-in your configuration. For example:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-Second, live-build supports #{*-desktop}# virtual package lists for each of
-the desktop flavours mentioned above, which select the #{standard-x11}#
-predefined package list, the corresponding #{*-desktop}# task and three
-additional tasks: #{desktop}#, #{standard}# and #{laptop}#. So, for example,
-if you specify #{--packages-lists gnome-desktop}#, it is equivalent to
-specifying #{--packages debian-installer-launcher --packages-lists
-standard-x11 --tasks "gnome-desktop desktop standard laptop"}#.
-
-Third, if any of the tasks for these desktop flavours are selected, either
-explicitly through #{--tasks}# or implicitly by #{--packages-lists}#,
-live-build will preseed the corresponding desktop value for Debian Installer
-(if it is included) to ensure it follows its own rules for installing
-different desktop flavours.
-
-*{Note:}* There is also an experimental #{--language}# option that has an overlapping purpose with language tasks. For any language for which it is known that there are #{*-l10n}# packages, if #{--language}# is specified, those packages will be installed. Furthermore, if any #{syslinux}# templates matching the language are found, they will be used instead of the default English templates. The package selection done by #{--language}# is a poor approximation of language tasks, as it requires that the list of packages to include per language be maintained internally in live-build, and besides, language tasks are more comprehensive and flexible. However, the #{syslinux}# aspect is still useful. Thus, if you use #{--bootloader syslinux}# and templates for the specified language exist either in #{/usr/share/live/build/templates/syslinux/}# or #{config/templates/syslinux/}#, consider using this option, possibly in combination with tasks to ensure all relevant packages are installed
. For example:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Even so, it is limited in that it only supports a single language and a
-single bootloader. Therefore, for all of these reasons, the future of this
-option is under review, possibly to be replaced with something entirely
-different in the next major release of live-build.
-
-2~installing-modified-or-third-party-packages Installing modified or
-third-party packages
-
-Whilst it is against the philosophy of Debian Live, it may sometimes be
-necessary to build a Live system with modified versions of packages that are
-in the Debian repository. This may be to modify or support additional
-features, languages and branding, or even to remove elements of existing
-packages that are undesirable. Similarly, "third-party" packages may be used
-to add bespoke and/or proprietary functionality.
-
-This section does not cover advice regarding building or maintaining
-modified packages. Joachim Breitner's 'How to fork privately' method from
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
-may be of interest, however. The creation of bespoke packages is covered in
-the Debian New Maintainers' Guide at http://www.debian.org/doc/maint-guide/
-and elsewhere.
-
-There are two ways of installing modified custom packages:
-
-_* #{chroot_local-packages}#
-
-_* Using a custom APT repository
-
-Using #{chroot_local-packages}# is simpler to achieve and useful for
-"one-off" customizations but has a number of drawbacks, whilst using a
-custom APT repository is more time-consuming to set up.
-
-3~ Using #{chroot_local-packages}# to install custom packages
-
-To install a custom package, simply copy it to the
-#{config/chroot_local-packages/}# directory. Packages that are inside this
-directory will be automatically installed into the live system during build
-- you do not need to specify them elsewhere.
-
-Packages *{must}* be named in the prescribed way. One simple way to do this
-is to use #{dpkg-name}#.
-
-Using #{chroot_local-packages}# for installation of custom packages has
-disadvantages:
-
-_* It is not possible to use secure APT.
-
-_* You must install all appropriate packages in the
-#{config/chroot_local-packages/}# directory.
-
-_* It does not lend itself to storing Debian Live configurations in revision
-control.
-
-3~ Using an APT repository to install custom packages
-
-Unlike using #{chroot_local-packages}#, when using a custom APT repository
-you must ensure that you specify the packages elsewhere. See {Choosing
-packages to install}#choosing-packages-to-install for details.
-
-Whilst it may seem unnecessary effort to create an APT repository to install
-custom packages, the infrastructure can be easily re-used at a later date to
-offer updates of the modified packages.
-
-3~ Custom packages and APT
-
-live-build uses APT to install all packages into the live system so will
-therefore inherit behaviours from this program. One relevant example is that
-(assuming a default configuration) given a package available in two
-different repositories with different version numbers, APT will elect to
-install the package with the higher version number.
-
-Because of this, you may wish to increment the version number in your custom
-packages' #{debian/changelog}# files to ensure that your modified version is
-installed over one in the official Debian repositories. This may also be
-achieved by altering the live system's APT pinning preferences - see {APT
-pinning}#apt-pinning for more information.
-
-2~ Configuring APT at build time
-
-You can configure APT through a number of options applied only at build
-time. (APT configuration used in the running live system may be configured
-in the normal way for live system contents, that is, by including the
-appropriate configurations through #{config/chroot_local_includes/}#.) For a
-complete list, look for options starting with #{apt}# in the #{lb_config}#
-man page.
-
-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.
-
-_* #{apt}#: With this method, if a missing package is specified, the package
-installation will fail. This is the default setting.
-
-_* #{aptitude}#: With this method, if a missing package is specified, the
-package installation will succeed.
-
-3~ Using a proxy with APT
-
-One commonly required APT configuration is to deal with building an image
-behind a proxy. You may specify your APT proxy with the #{--apt-ftp-proxy}#
-or #{--apt-http-proxy}# options as needed, e.g.
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Tweaking APT to save space
-
-You may find yourself needing to save some space on the image media, in
-which case one or the other or both of the following options may be of
-interest.
-
-If you don't want to include APT indices in the image, you can omit those
-with:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-This will not influence the entries in /etc/apt/sources.list, but merely
-whether /var/lib/apt contains the indices files or not. The tradeoff is that
-APT needs those indices in order to operate in the live system, so before
-performing #{apt-cache search}# or #{apt-get install}#, for instance, the
-user must #{apt-get update}# first to create those indices.
-
-If you find the installation of recommended packages bloats your image too
-much, you may disable that default option of APT with:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-The tradeoff here is that if you don't install recommended packages for a
-given package, that is, "packages that would be found together with this one
-in all but unusual installations" (Debian Policy Manual, section 7.2), some
-packages that you actually need may be omitted. Therefore, we suggest you
-review the difference turning off recommends makes to your packages list
-(see the #{binary.packages}# file generated by #{lb build}#) and re-include
-in your list any missing packages that you still want
-installed. Alternatively, if you find you only want a small number of
-recommended packages left out, leave recommends enabled and set a negative
-APT pin priority on selected packages to prevent them from being installed,
-as explained in {APT pinning}#apt-pinning.
-
-3~ Passing options to apt or aptitude
-
-If there is not an #{lb config}# option to alter APT's behaviour in the way
-you need, use #{--apt-options}# or #{--aptitude-options}# to pass any
-options through to your configured APT tool. See the man pages for #{apt}#
-and #{aptitude}# for details.
-
-3~apt-pinning APT pinning
-
-For background, please first read the #{apt_preferences(5)}# man page. APT
-pinning can be configured either for build time, or else for run time. For
-the former, create #{config/chroot_apt/preferences}#. For the latter, create
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Let's say you are building a Squeeze live system but need all the live
-packages that end up in the binary image to be installed from Sid at build
-time. You need to add Sid to your APT sources and pin it so that only the
-packages you want are installed from it at build time and all others are
-taken from the target system distribution, Squeeze. The following will
-accomplish this:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Note:}* Wildcards can be used in package names (e.g. *{Package: live-*}*) with Apt version 0.8.14 or higher. This means that it works with Wheezy using:
-
-code{
-
-$ 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 #{--packages-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{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/pt_BR/user_customization-runtime.ssi b/manual/pt_BR/user_customization-runtime.ssi
deleted file mode 100644
index 4bbf347..0000000
--- a/manual/pt_BR/user_customization-runtime.ssi
+++ /dev/null
@@ -1,229 +0,0 @@
-:B~ Customizing run time behaviours
-
-1~customizing-run-time-behaviours Customizing run time behaviours
-
-All configuration that is done during run time is done by live-config. Here
-are some of the most common options of live-config that users are interested
-in. A full list of all possibilities can be found in the manpage of
-live-config.
-
-2~ Customizing the live user
-
-One important consideration is that the live user is created by live-boot at
-boot time, not by live-build at build time. This not only influences where
-materials relating to the live user are introduced in your build, as
-discussed in {Live/chroot local includes}#live-chroot-local-includes, but
-also any groups and permissions associated with the live user.
-
-You can specify additional groups that the live user will belong to by
-preseeding the #{passwd/user-default-groups}# debconf value. For example, to
-add the live user to the #{fuse}# group, add the following to a file in the
-#{config/chroot_local-preseed}# directory:
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-It is also possible to change the default username "user" and the default
-password "live". If you want to do that for any reason, you can easily
-achieve it as follows:
-
-To change the default username you can simply specify it in your config:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-One possible way of changing the default password is by means of a hook as
-described in {Boot-time hooks}#boot-time-hooks. In order to do that you can
-use the "passwd" hook from #{/usr/share/doc/live-config/examples/hooks}#,
-prefix it accordingly (e.g. 200-passwd) and add it to
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Customizing locale and language
-
-When the live system boots, language is involved in three steps:
-
-_* the locale generation
-
-_* setting the keyboard layout for the console
-
-_* setting the keyboard layout for X
-
-The default locale when building a Live system is "locales=en_US.UTF-8". To
-define the locale that should be generated, use the #{locales}# parameter in
-the #{--bootappend-live}# option of #{lb config}#, e.g.
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-This parameter can also be used at the kernel command line. You can specify
-a locale by a full #{language_country.encoding}# word.
-
-Both the console and X keyboard configuration depend on the
-#{keyboard-layouts}# parameter of the #{--bootappend-live}# option. Valid
-options for X keyboard layouts can be found in
-#{/usr/share/X11/xkb/rules/base.xml}# (rather limited to two-letters country
-codes). To find the value (the two characters) corresponding to a language
-try searching for the english name of the nation where the language is
-spoken, e.g:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-To get the locale files for German and Swiss German keyboard layout in X
-use:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-A list of the valid values of the keyboards for the console can be figured
-with the following command:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-Alternatively, you can use the #{console-setup}# package, a tool to let you
-configure console layout using X (XKB) definitions; you can then set your
-keyboard layout more precisely with #{keyboard-layouts}#,
-#{keyboard-variant}#, #{keyboard-options}# and #{keyboard-model}# variables;
-live-boot will use also these parameters for X configuration. For example,
-to set up a French system with a French-Dvorak layout (called Bepo) on a
-TypeMatrix keyboard, both in console and X11, use:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistence
-
-A live cd paradigm is a pre-installed system which runs from read-only
-media, like a cdrom, where writes and modifications do not survive reboots
-of the host hardware which runs it.
-
-A Debian Live system is a generalization of this paradigm and thus supports
-other media in addition to CDs; but still, in its default behaviour, it
-should be considered read-only and all the run-time evolutions of the system
-are lost at shutdown.
-
-Persistence is a common name for different kinds of solutions for saving
-across reboots some, or all, of this run-time evolution of the system. To
-understand how it could work it could be handy to know that even if the
-system is booted and run from read-only media, modification to the files and
-directories are written on writable media, typically a ram disk (tmpfs) and
-ram disks' data do not survive reboots.
-
-The data stored on this ramdisk should be saved on a writable persistent
-medium like a Hard Disk, a USB key, a network share or even a session of a
-multisession (re)writable CD/DVD. All these media are supported in Debian
-Live in different ways, and all but the last one require a special boot
-parameter to be specified at boot time: #{persistent}#.
-
-3~ Full persistence
-
-By 'full persistence' it is meant that instead of using a tmpfs for storing
-modifications to the read-only media (with the copy-on-write, COW, system) a
-writable partition is used. In order to use this feature a partition with a
-clean writable supported filesystem on it labeled "live-rw" must be attached
-on the system at boot time and the system must be started with the boot
-parameter 'persistent'. This partition could be an ext2 partition on the
-hard disk or on a usb key created with, e.g.:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-See also {Using the space left on a USB stick}#using-usb-extra-space.
-
-If you already have a partition on your device, you could just change the
-label with one of the following:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-But since live system users cannot always use a hard drive partition, and
-considering that most USB keys have poor write speeds, 'full' persistence
-could be also used with just image files, so you could create a file
-representing a partition and put this image file even on a NTFS partition of
-a foreign OS, with something like:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-Then copy the #{live-rw}# file to a writable partition and reboot with the
-boot parameter 'persistent'.
-
-3~ Home automounting
-
-If during the boot a partition (filesystem) image file or a partition
-labeled #{home-rw}# is discovered, this filesystem will be directly mounted
-as #{/home}#, thus permitting persistence of files that belong to e.g. the
-default user. It can be combined with full persistence.
-
-3~ Snapshots
-
-Snapshots are collections of files and directories which are not mounted
-while running but which are copied from a persistent device to the system
-(tmpfs) at boot and which are resynced at reboot/shutdown of the system. The
-content of a snapshot could reside on a partition or an image file (like the
-above mentioned types) labeled #{live-sn}#, but it defaults to a simple cpio
-archive named #{live-sn.cpio.gz}#. As above, at boot time, the block devices
-connected to the system are traversed to see if a partition or a file named
-like that could be found. A power interruption during run time could lead to
-data loss, hence a tool invoked #{live-snapshot --refresh}# could be called
-to sync important changes. This type of persistence, since it does not write
-continuously to the persistent media, is the most flash-based device
-friendly and the fastest of all the persistence systems.
-
-A /home version of snapshot exists too and its label is #{home-sn.*}#; it
-works the same as the main snapshot but it is only applied to /home.
-
-Snapshots cannot currently handle file deletion but full persistence and
-home automounting can.
-
-3~ Persistent SubText
-
-If a user would need multiple persistent storage of the same type for
-different locations or testing, such as #{live-rw-nonwork}# and
-#{live-rw-work}#, the boot parameter #{persistent-subtext}# used in
-conjunction with the boot parameter #{persistent}# will allow for multiple
-but unique persistent media. An example would be if a user wanted to use a
-persistent partition labeled #{live-sn-subText}# they would use the boot
-parameters of: #{persistent}# #{persistent-subtext=subText}#.
-
-3~ Partial remastering
-
-The run-time modification of the tmpfs could be collected using
-live-snapshot in a squashfs and added to the cd by remastering the iso in
-the case of cd-r or adding a session to multisession cd/dvd(rw); live-boot
-mounts all /live filesystem in order or with the module boot parameter.
diff --git a/manual/pt_BR/user_examples.ssi b/manual/pt_BR/user_examples.ssi
deleted file mode 100644
index 5bb918a..0000000
--- a/manual/pt_BR/user_examples.ssi
+++ /dev/null
@@ -1,395 +0,0 @@
-:B~ Examples
-
-1~examples Examples
-
-This chapter covers example builds for specific use cases with Debian
-Live. If you are new to building your own Debian Live images, we recommend
-you first look at the three tutorials in sequence, as each one teaches new
-techniques that will help you use and understand the remaining examples.
-
-2~using-the-examples Using the examples
-
-To use these examples you need a system to build them on that meets the
-requirements listed in {Requirements}#requirements and has live-build
-installed as described in {Installing live-build}#installing-live-build.
-
-Note that, for the sake of brevity, in these examples we do not specify a
-local mirror to use for the build. You can speed up downloads considerably
-if you use a local mirror. You may specify the options when you use #{lb
-config}#, as described in {Distribution mirrors used at build
-time}#distribution-mirrors-build-time, or for more convenience, set the
-default for your build system in #{/etc/live/build.conf}#. Simply create
-this file and in it, set the corresponding #{LB_MIRROR_*}# variables to your
-preferred mirror. For example:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: A standard image
-
-*{Use case:}* Create a simple first image, learning the basics of live-build.
-
-In this tutorial, we will build a default ISO hybrid Debian Live image
-containing only base packages (no Xorg) and some Debian Live support
-packages, as a first exercise in using live-build.
-
-You can't get much simpler than this:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Examine the contents of the #{config/}# directory if you wish. You will see
-stored here a skeletal configuration, ready to customize or, in this case,
-use immediately to build a default image.
-
-Now, as superuser, build the image, saving a log as you build with #{tee}#.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Assuming all goes well, after a while, the current directory will contain
-#{binary-hybrid.iso}#. This ISO hybrid image can be booted directly in a
-virtual machine as described in {Testing an ISO image with
-Qemu}#testing-iso-with-qemu and {Testing an ISO image with
-virtualbox-ose}#testing-iso-with-virtualbox, or else imaged onto optical
-media or a USB flash device as described in {Burning an ISO image to a
-physical medium}#burning-iso-image and {Copying an ISO hybrid image to a USB
-stick}#copying-iso-hybrid-to-usb, respectively.
-
-2~tutorial-2 Tutorial 2: A web browser utility
-
-*{Use case:}* Create a web browser utility image, learning how to apply customizations.
-
-In this tutorial, we will create an image suitable for use as a web browser
-utility, serving as an introduction to customizing Debian Live images.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-Our choice of LXDE for this example reflects our desire to provide a minimal
-desktop environment, since the focus of the image is the single use we have
-in mind, the web browser. We could go even further and provide a default
-configuration for the web browser in
-#{config/chroot_local-includes/etc/iceweasel/profile/}#, or additional
-support packages for viewing various kinds of web content, but we leave this
-as an exercise for the reader.
-
-Build the image, again as superuser, keeping a log as in {Tutorial
-1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Again, verify the image is OK and test, as in {Tutorial 1}#tutorial-1.
-
-2~tutorial-3 Tutorial 3: A personalized image
-
-*{Use case:}* Create a project to build a personalized image, containing your favourite software to take with you on a USB stick wherever you go, and evolving in successive revisions as your needs and preferences change.
-
-Since we will be changing our personalized image over a number of revisions,
-and we want to track those changes, trying things experimentally and
-possibly reverting them if things don't work out, we will keep our
-configuration in the popular #{git}# version control system. We will also
-use the best practice of autoconfiguration via #{auto}# scripts as described
-in {Managing a configuration}#managing-a-configuration.
-
-3~ First revision
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Edit #{auto/config}# to read as follows:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-First, #{--architecture 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}# 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:
-
-code{
-
- # lb build
-
-}code
-
-Note that unlike in the first two tutorials, we no longer have to type
-#{2>&1 | tee binary.log}# as that is now included in #{auto/build}#.
-
-Once you've tested the image (as in {Tutorial 1}#tutorial-1) and are
-satisfied it works, it's time to initialize our #{git}# repository, adding
-only the auto scripts we just created, and then make the first commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Second revision
-
-In this revision, we're going to clean up from the first build, add the
-#{vlc}# package to our configuration, rebuild, test and commit.
-
-The #{lb clean}# command will clean up all generated files from the previous
-build except for the cache, which saves having to re-download packages. This
-ensures that the subsequent #{lb build}# will re-run all stages to
-regenerate the files from our new configuration.
-
-code{
-
- # lb clean
-
-}code
-
-Now edit #{auto/config}# to add the #{vlc}# package:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Build again:
-
-code{
-
-# lb build
-
-}code
-
-Test, and when you're satisfied, commit the next revision:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Of course, more complicated changes to the configuration are possible,
-perhaps adding files in subdirectories of #{config/}#. When you commit new
-revisions, just take care not to hand edit or commit the top-level files in
-#{config}# containing #{LB_*}# variables, as these are build products, too,
-and are always cleaned up by #{lb clean}# and re-created with #{lb config}#
-via their respective #{auto}# scripts.
-
-We've come to the end of our tutorial series. While many more kinds of
-customization are possible, even just using the few features explored in
-these simple examples, an almost infinite variety of different images can be
-created. The remaining examples in this section cover several other use
-cases drawn from the collected experiences of users of Debian Live.
-
-2~ A VNC Kiosk Client
-
-*{Use case:}* Create an image with live-build to boot directly to a VNC server.
-
-Make a build directory and create a skeletal configuration in it built
-around the standard-x11 list, including #{gdm3}#, #{metacity}# and
-#{xtightvncviewer}#, disabling recommends to make a minimal system:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Create the directory #{/etc/skel}# and put a custom #{.xsession}# in it for
-the default user that will launch metacity and start xvncviewer, connecting
-to port #{5901}# on a server at #{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Build the image:
-
-code{
-
- # lb build
-
-}code
-
-Enjoy.
-
-2~ A base image for a 128M USB key
-
-*{Use case:}* Create a standard image with some components removed in order to fit on a 128M USB key with space left over to use as you see fit.
-
-When optimizing an image to fit a certain media size, you need to understand
-the tradeoffs you are making between size and functionality. In this
-example, we trim only so much as to make room for additional material within
-a 128M media size, but without doing anything to destroy integrity of the
-packages contained within, such as the purging of locale data via the
-#{localepurge}# package, or other such "intrusive" optimizations. Of
-particular note, you should not use #{--bootstrap-flavour minimal}# unless
-you really know what you're doing, as omitting priority #{important}#
-packages will most likely produce a broken live system.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Now, build the image in the usual way:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-On the author's system at time of writing, the above configuration produced
-a 78Mbyte image. This compares favourably with the 166Mbyte image produced
-by the default configuration in {Tutorial 1}#tutorial-1.
-
-The biggest space-saver here, compared to building a standard image on an
-#{i386}# architecture system, is to select only the #{486}# kernel flavour
-instead of the default #{-k "486 686"}#. Leaving off APT's indices with
-#{--binary-indices false}# also saves a fair amount of space, the tradeoff
-being that you need to #{apt-get update}# before using apt in the live
-system. Choosing the #{minimal}# package list leaves out the large
-#{locales}# package and associated utilities. Dropping recommended packages
-with #{--apt-recommends false}# saves some additional space, at the expense
-of omitting some packages you might otherwise expect to be there, such as
-#{firmware-linux-free}# which may be needed to support certain hardware. The
-remaining options shave off additional small amounts of space. It's up to
-you to decide if the functionality that is sacrificed with each optimization
-is worth the loss in functionality.
-
-2~ A localized KDE desktop and installer
-
-*{Use case:}* Create a KDE desktop image, localized for Brazilian Portuguese and including an installer.
-
-We want to make an iso-hybrid image for i386 architecture using our
-preferred desktop, in this case KDE, containing all of the same packages
-that would be installed by the standard Debian installer for KDE.
-
-Our initial problem is the discovery of the names of the appropriate
-tasks. Currently, live-build cannot help with this. While we might get lucky
-and find this by trial-and-error, there is a tool, #{grep-dctrl}#, which can
-be used to dig it out of the task descriptions in tasksel-data, so to
-prepare, make sure you have both of those things:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Now we can search for the appropriate tasks, first with:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-By this command, we discover the task is called, plainly enough,
-brazilian-portuguese. Now to find the related tasks:
-
-code{
-
- $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-We will use the experimental #{--language}# option, as live-build happens to
-include #{syslinux}# templates for pt_BR (see {Desktop and language
-tasks}#desktop-and-language-tasks for details). And at boot time we will
-generate the pt_BR.UTF-8 locale and select the pt-latin1 keyboard
-layout. Now let's put the pieces together:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Note that we have included the #{debian-installer-launcher}# package to
-launch the installer from the live desktop, and have also specified the 486
-flavour kernel, as it is currently necessary to make the installer and live
-system kernels match for the launcher to work properly.
diff --git a/manual/pt_BR/user_installation.ssi b/manual/pt_BR/user_installation.ssi
deleted file mode 100644
index badc83f..0000000
--- a/manual/pt_BR/user_installation.ssi
+++ /dev/null
@@ -1,174 +0,0 @@
-:B~ Installation
-
-1~installation Installation
-
-2~requirements Requirements
-
-Building Debian Live images has very few system requirements:
-
-_* Super user (root) access
-
-_* An up-to-date version of live-build
-
-_* A POSIX-compliant shell, such as /{bash}/ or /{dash}/.
-
-_* /{debootstrap}/ or /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Note that using Debian or a Debian-derived distribution is not required -
-live-build will run on almost any distribution with the above requirements.
-
-2~installing-live-build Installing live-build
-
-You can install live-build in a number of different ways:
-
-_* From the Debian repository
-
-_* From source
-
-_* From snapshots
-
-If you are using Debian, the recommended way is to install live-build via
-the Debian repository.
-
-3~ From the Debian repository
-
-Simply install live-build like any other package:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-or
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ From source
-
-live-build is developed using the Git version control system. On Debian
-based systems, this is provided by the /{git}/ package. To check out the
-latest code, execute:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-You can build and install your own Debian package by executing:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Now install whichever of the freshly built #{.deb}# files you were
-interested in, e.g.
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-You can also install live-build directly to your system by executing:
-
-code{
-
- # make install
-
-}code
-
-and uninstall it with:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ From 'snapshots'
-
-If you do not wish to build or install live-build from source, you can use
-snapshots. These are built automatically from the latest version in Git and
-are available on http://live.debian.net/debian/.
-
-2~ live-boot and live-config
-
-*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes. If you only want the documentation, you may now install the live-boot-doc and live-config-doc packages separately.
-
-3~ From the Debian repository
-
-Both live-boot and live-config are available from the Debian repository as
-per {Installing live-build}#installing-live-build.
-
-3~ From source
-
-To use the latest source from git, you can follow the process below. Please
-ensure you are familiar with the terms mentioned in {Terms}#terms.
-
-_* Checkout the live-boot and live-config source
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Consult the live-boot and live-config man pages for details on customizing
-if that is your reason for building these packages from source.
-
-_* Build live-boot and live-config .deb files
-
-You must build either on your target distribution or in a chroot containing
-your target platform: this means if your target is Squeeze then you should
-build against Squeeze.
-
-Use a personal builder such as /{pbuilder}/ or /{sbuild}/ if you need to
-build #{live-boot}# for a target distribution that differs from your build
-system. For example, for Squeeze live images, build #{live-boot}# in a
-Squeeze chroot. If your target distribution happens to match your build
-system distribution, you may build directly on the build system using
-#{dpkg-buildpackage}# (provided by the /{dpkg-dev}/ package):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Use all generated .deb files
-
-As live-boot and live-config are installed by live-build system, installing
-the packages in the host system is not sufficient: you should treat the
-generated .deb files like any other custom packages. Please see {Customizing
-package installation}#customizing-package-installation for more
-information. You should pay particular attention to {Additional
-repositories}#additional-repositories.
-
-3~ From 'snapshots'
-
-You can let live-build automatically use the latest snapshots of live-boot
-and live-config by configuring a third-party repository in your live-build
-configuration directory. Assuming you have already created a configuration
-tree in the current directory with #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/pt_BR/user_managing_a_configuration.ssi b/manual/pt_BR/user_managing_a_configuration.ssi
deleted file mode 100644
index 999c508..0000000
--- a/manual/pt_BR/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,94 +0,0 @@
-:B~ Managing a configuration
-
-1~managing-a-configuration Managing a configuration
-
-This chapter explains how to manage a live configuration from initial
-creation, through successive revisions and successive releases of both the
-live-build software and the live image itself.
-
-2~ Use auto to manage configuration changes
-
-Live configurations rarely are perfect on the first try. You'll likely need
-to make a series of revisions until you are satisfied. However,
-inconsistencies can creep into your configuration from one revision to the
-next if you aren't careful. The main problem is, once a variable is given a
-default value, that value will not be recomputed from other variables that
-may change in later revisions.
-
-For example, when the distribution is first set, many 'dependent' variables
-are given default values that suit that distribution. However, if you later
-decide to change the distribution, those dependent variables continue to
-retain old values that are no longer appropriate.
-
-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 #{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).
-
-2~ Example auto scripts
-
-Use auto script examples such as the following as the starting point for
-your new live-build configuration. Take note that when you call the #{lb}#
-command that the auto script wraps, you must specify #{noauto}# as its
-parameter to ensure that the auto script isn't called again,
-recursively. Also, don't forget to ensure the scripts are executable
-(e.g. #{chmod 755 auto/*}#).
-
-#{auto/config}#
-
-code{
-
- #!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-We now ship example auto scripts with live-build based on the examples
-above. You may copy those as your starting point.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Edit #{auto/config}#, changing or adding any options as you see fit. In the
-example above, #{--packages-lists standard}# is set to the default
-value. Change this to an appropriate value for your image (or delete it if
-you want to use the default) and add any additional options in continuation
-lines that follow.
diff --git a/manual/pt_BR/user_overview.ssi b/manual/pt_BR/user_overview.ssi
deleted file mode 100644
index ddb3b58..0000000
--- a/manual/pt_BR/user_overview.ssi
+++ /dev/null
@@ -1,158 +0,0 @@
-:B~ Overview of tools
-
-1~overview-of-tools Overview of tools
-
-This chapter contains an overview of the three main tools used in building
-Debian Live systems: live-build, live-boot and live-config.
-
-2~live-build live-build
-
-live-build is a collection of scripts to build Debian Live systems. These
-scripts are also referred to as "commands".
-
-The idea behind live-build is to be a framework that uses a configuration
-directory to completely automate and customize all aspects of building a
-Live image.
-
-Many concepts are similar to those in the debhelper Debian package tools
-written by Joey Hess:
-
-_* The scripts have a central location for configuring their operation. In
-debhelper, this is the #{debian/}# subdirectory of a package tree. For
-example, dh_install will look, amongst others, for a file called
-#{debian/install}# to determine which files should exist in a particular
-binary package. In much the same way, live-build stores its configuration
-entirely under a #{config/}# subdirectory.
-
-_* 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.
-
-The remainder of this section discusses the three most important commands:
-
-_* *{lb config}*: Responsible for initializing a Live system configuration
-directory. See {The lb config command}#lb-config for more information.
-
-_* *{lb build}*: Responsible for starting a Live system build. See {The lb
-build command}#lb-build for more information.
-
-_* *{lb clean}*: Responsible for removing parts of a Live system build. See
-{The lb clean command}#lb-clean for more information.
-
-3~lb-config The #{lb config}# command
-
-As discussed in {live-build}#live-build, the scripts that make up live-build
-read their configuration with the #{source}# command from a single directory
-named #{config/}#. As constructing this directory by hand would be
-time-consuming and error-prone, the #{lb config}# command can be used to
-create skeleton configuration folders.
-
-Issuing #{lb config}# without any arguments creates a #{config/}#
-subdirectory which it populates with some default settings:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-Using #{lb config}# without any arguments would be suitable for users who
-need a very basic image, or who intend to later provide a more complete
-configuration via auto/config (see {Managing a
-configuration}#managing-a-configuration for details).
-
-Normally, you will want to specify some options. For example, to include the
-'gnome' package list in your configuration:
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-It is possible to specify many options, such as:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-A full list of options is available in the #{lb_config}# man page.
-
-3~lb-build The #{lb build}# command
-
-The #{lb build}# command reads in your configuration from the config/
-directory. It then runs the lower level commands needed to build your Live
-system.
-
-3~lb-clean The #{lb clean}# command
-
-It is the job of the #{lb clean}# command to remove various parts of a build
-so subsequent builds can start from a clean state. By default, #{chroot}#,
-#{binary}# and #{source}# stages are cleaned, but the cache is left
-intact. Also, individual stages can be cleaned. For example, if you have
-made changes that only affect the binary stage, use #{lb clean --binary}#
-prior to building a new binary. See the #{lb_clean}# man page for a full
-list of options.
-
-2~live-boot The live-boot package
-
-live-boot is a collection of scripts providing hooks for the
-initramfs-tools, used to generate an initramfs capable of booting live
-systems, such as those created by live-build. This includes the Debian Live
-ISOs, netboot tarballs, and USB stick images.
-
-At boot time it will look for read-only media containing a "/live" directory
-where a root filesystem (often a compressed filesystem image like squashfs)
-is stored. If found, it will create a writable environment, using aufs, for
-Debian like systems to boot from.
-
-More information on initial ramfs in Debian can be found in the Debian Linux
-Kernel Handbook at http://kernel-handbook.alioth.debian.org/ in the chapter
-on initramfs.
-
-2~live-config The live-config package
-
-live-config consists of the scripts that run at boot time after live-boot to
-configure the live system automatically. It handles such tasks as setting
-the hostname, locales and timezone, creating the live user, inhibiting cron
-jobs and performing autologin of the live user.
diff --git a/manual/ro/_sisu/.empty b/manual/ro/_sisu/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/ro/_sisu/image/.empty b/manual/ro/_sisu/image/.empty
deleted file mode 100644
index e69de29..0000000
diff --git a/manual/ro/_sisu/sisurc.yml b/manual/ro/_sisu/sisurc.yml
deleted file mode 100644
index 788cd67..0000000
--- a/manual/ro/_sisu/sisurc.yml
+++ /dev/null
@@ -1,126 +0,0 @@
-# Name: SiSU - Simple information Structuring Universe
-# Author: Ralph at Amissah.com
-# Description: Site wide envionment defaults set here
-# system environment info / resource configuration file, for sisu
-# License: GPL v3 or later
-# site environment configuration file
-# this file should be configured and live in
-# /etc/sisu #per environment settings, overridden by:
-# ~/.sisu #per user settings, overridden by:
-# ./_sisu #per local markup directory settings
-#% #image source directory, main path and subdirectories
-#image:
-# path: 'sisu_working'
-# public: '_sisu/image'
-# #all: 'image'
-#% presentation/web directory, main path and subdirectories (most subdirectories are created automatically based on markup directory name)
-webserv:
- path: 'build'
- url_root: 'http://live.debian.net/manual' #without dir stub
-# images: '_sisu/image'
-# man: 'man'
-# cgi: '/usr/lib/cgi-bin'
-# feed: 'feed'
-# sqlite: 'sisu/sqlite'
-# webrick_url: true
-#show_output_on: 'filesystem' #for -v and -u url information, alternatives: 'filesystem','webserver','remote_webserver','local:8111','localhost','localhost:8080','webrick','path'
-#show_output_on: 'local:8111'
-#webserv_cgi:
-# host: localhost
-# base_path: ~
-# port: '8081'
-# user: ~
-show_output_on: 'filesystem_url'
-#texinfo display output
-#texinfo:
-# stub: 'texinfo'
-##% processing directories, main path and subdirectories (appended to $HOME), using defaults set in sysenv
-#processing:
-# path: '~'
-# dir: '.sisu_processing~'
-# metaverse: 'metaverse'
-# tune: 'tune'
-# latex: 'tex'
-# texinfo: 'texinfo'
-# concord_max: 400000
-#% flag - set (non-default) processing flag shortcuts -1, -2 etc. (here adding colour and verbosity as default)
-flag:
- color: true # making colour default -c is toggle, and will now toggle colour off
- default: '-NhwepoabxXyYv' # -m run by default; includes verbose
- i: '-hwpoay' # -m run by default
- ii: '-NhwepoabxXy' # -m run by default
- iii: '-NhwepoabxXyY' # -m run by default
- iv: '-NhwepoabxXYDy --update' # -m run by default
- v: '-NhwepoabxXYDyv --update' # -m run by default; includes verbose
-#% papersize, (LaTeX/pdf) available values: A4, US_letter, book_b5, book_a5, US_legal
-default:
- papersize: 'A4,letter'
- #texpdf_font: 'Liberation Serif' # 'Liberation Sans' 'Liberation Serif'
- #text_wrap: 78
- #emphasis: 'bold' #make *{emphasis}* 'bold', 'italics' or 'underscore', default if not configured is 'bold'
- #digest: 'sha' #sha is sha256, default is md5
- #multilingual: false
- #language_file: 2
- #language: 'English'
-#% markup, make *{emphasis}* 'bold' or 'italics', default if not configured is 'bold'
-#% settings used by ssh scp
-#remote:
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-# -
-# user: '[usrname]'
-# host: '[remote.hostname]'
-# path: '.' #no trailing slash eg 'sisu/www'
-#% webrick information
-#webrick:
-# port: '8081'
-#% sql database info, postgresql and sqlite
-#db:
-# share_source: false # boolean, default is false
-# postgresql:
-# port: # '[port (default is 5432)]'
-# host: # '[if not localhost, provide host tcp/ip address or domain name]''
-# user: # '[(if different from user) provide username]'
-# password: # '[password if required]'
-# sqlite:
-# path: ~ # './sisu_sqlite.db'
-# port: "**"
-#% possible values ~, true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'.
-#will only ignore if value set to false, absence or nil will not remove program as should operate without rc file
-#ie in case of ~ will ignore and use hard coded defaults within program), true, false, or command instruction e.g. editor: 'gvim -c :R -c :S'
-#on value true system defaults used, to change, e.g. editor specify
-permission_set:
- zap: false
- css_modify: false
-# remote_base_site: true
-program_set:
- rmagick: false
-# wc: true
-# editor: true
-# postgresql: true
-# sqlite: true
-# tidy: true
-# rexml: true
-# pdflatex: true
-#program_select:
-# editor: 'gvim -c :R -c :S'
-# pdf_viewer: 'evince'
-# web_browser: 'firefox' #'iceweasel' #'epiphany' #'galeon' #'konqueror' #'kazehakase'
-# console_www_browser: 'links2' #'elinks' #'w3m' #'lynx' #'links'
-# epub_viewer: 'ebook-viewer' #'calibre' #'okular' #'fbreader'
-# odf_viewer: 'oowriter' #'abiword'
-# xml_viewer: 'xml-viewer'
-# man: 'nroff -man' #'groff -man -Tascii' # 'nroff -man'
-#promo: sisu_icon, sisu, sisu_search_libre, open_society, fsf, ruby
-#search:
-# sisu:
-# flag: true
-## action: http://localhost:8081/cgi-bin/sisu_pgsql.cgi
-# action: http://search.sisudoc.org
-# db: sisu
-# title: sample search form
-# hyperestraier:
-# flag: true
-# action: http://search.sisudoc.org/cgi-bin/estseek.cgi?
diff --git a/manual/ro/_sisu/skin/doc/skin_debian-live.rb b/manual/ro/_sisu/skin/doc/skin_debian-live.rb
deleted file mode 100644
index 137636c..0000000
--- a/manual/ro/_sisu/skin/doc/skin_debian-live.rb
+++ /dev/null
@@ -1,79 +0,0 @@
-module SiSU_Viz
- require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb>
- class Skin
- #% path
- def path_root
- './sisu/' # the only parameter that cannot be changed here
- end
- def path_rel
- '../'
- end
- #% url
- def url_root_http
- 'http://live.debian.net/manual/'
- end
- def url_home
- 'http://live.debian.net/'
- end
- def url_site # used in pdf header
- 'http://live.debian.net'
- end
- def url_txt # text to go with url usually stripped url
- ''
- end
- def url_home_url
- '../index.html'
- end
- def url_footer_signature
- ''
- end
- #% color
- def color_band1
- '"#ffffff"'
- end
- def color_band2
- '"#ffffff"'
- end
- #% txt
- def txt_hp
- ' Debian'
- end
- def txt_home
- 'Debian'
- end
- def txt_signature
- ''
- end
- #% icon
- def icon_home_button
- 'debian_home.png'
- end
- def icon_home_banner
- home_button
- end
- #% banner
- def banner_home_button
- %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n}
- end
- def banner_home_and_index_buttons
- %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}}
- end
- def banner_band
- %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}}
- end
- end
- class TeX
- def header_center
- "\\chead{\\href{#{@vz.url_site}/}{live.debian.net}}"
- end
- def home_url
- "\\href{#{@vz.url_site}/}{live.debian.net}"
- end
- def home
- "\\href{#{@vz.url_site}/}{Debian Live}"
- end
- def owner_chapter
- "Document owner details"
- end
- end
-end
diff --git a/manual/ro/about_manual.ssi b/manual/ro/about_manual.ssi
deleted file mode 100644
index ecafa34..0000000
--- a/manual/ro/about_manual.ssi
+++ /dev/null
@@ -1,269 +0,0 @@
-:B~ Despre acest manual
-
-1~about-manual Despre acest manual
-
-The main goal of this manual is to serve as a single access point to all
-documentation related to the Debian Live project. While it is primarily
-focused on helping you build a live system and not on end-user topics, an
-end-user may find some useful information in these sections: {The
-Basics}#the-basics covers preparing images to be booted from media or the
-network, and {Customizing run time
-behaviours}#customizing-run-time-behaviours describes some options that may
-be specified at the boot prompt, such as selecting a keyboard layout and
-locale, and using persistence.
-
-Anumite comenzi din text trebuie sa fie executate ca 'super_utilizator',
-privilegiu care poate fi obtinut fie prin comanda #{su}, sau #{sudo}. Pentru
-a distinge intre acesti utilizatori se vor folosi #{$}# respectiv #{#}#
-. Aceste simboluri nu fac parte din comenzi.
-
-2~ For the impatient
-
-While we believe that everything in this manual is important to at least
-some of our users, we realize it is a lot of material to cover and that you
-may wish to experience early success using the software before delving into
-the details. Therefore, we have provided three tutorials in the
-{Examples}#examples section designed to teach you image building and
-customization basics. Read {Using the examples}#using-the-examples first,
-followed by {Tutorial 1: A standard image}#tutorial-1, {Tutorial 2: A web
-browser utility}#tutorial-2 and finally {Tutorial 3: A personalized
-image}#tutorial-3. By the end of these tutorials, you will have a taste of
-what can be done with Debian Live. We encourage you to return to more
-in-depth study of the manual, perhaps next reading {The basics}#the-basics,
-skimming or skipping {Building a netboot image}#building-netboot-image, and
-finishing by reading the {Customization overview}#customization-overview and
-the chapters that follow it. By this point, we hope you are thoroughly
-excited by what can be done with Debian Live and motivated to read the rest
-of the manual, cover-to-cover.
-
-2~terms Termeni
-
-_* *{Live system}*: Un sistem de operare care porneste fara a instala pe
-discul dur. Un sistem live nu altereaza un sistem de operare local sau
-fisiere deja instalate pe discul dur ci doar dace se mentioneaza expres
-acest lucru. Sistemele livefolosesc spre pornire medii ca CDs, DVDs sau chei
-USB. Unele chiar pot porni prin retaua de net.
-
-_* *{Debian Live}*: Sub-proiectul Debian care gereaza pachetele live-boot,
-live-build, live-config, si live-manual.
-
-_* *{Debian Live system}*: Un sistem live care foloseste programe din
-sitemul de operare Debian, si care poate fi pornit folosind CDs, DVDs, chei
-USB, sau reteaua net (via netboot images), sau prin nternet (via boot
-parameter #{fetch=URL}#).
-
-_* *{Host system}*: Mediul folosit pentru crearea sistemului live pe un
-sistem dat.
-
-_* *{Target system}*: Mediul folosit pentru rularea sistemului live.
-
-_* *{live-boot}*: O coloctie se scripte folosite la pornirea sistemului
-live. live-boot a facul parte formal din live-initramfs.
-
-_* *{live-build}*: O colectie de scripte folosite la particularizatrea
-sistemelor Debian Live. live-build a fost cunoscut ca live-helper, iar mai
-inainte ca live-package.
-
-_* *{live-config}*: O colectie de scripte folosite la configurarea sitemului
-live in timpul procesului de pornire. live-config a fost cunoscut ca parte
-din live-initramfs.
-
-_* *{live-manual}*: Acest document face parte din pachetul numit
-live-manual.
-
-_* *{Debian Installer (d-i)}*: Sistemul de instalare oficial pentru
-distributia Debian.
-
-_* *{Boot parameters}*: Parameti care pot fi adaugati la promptul
-bootloader-ului care sa infuenteze kernelul sau live-config.
-
-_* *{chroot}*: Programul chroot, #{chroot(8)}#, permite rularea a diferite
-instante din mediul GNU/Linux pe un singur sistem si in simultan fara a
-necesita o repornire a sistemului.
-
-_* *{Binary image}*: Un fisier ce contine sistemul live, ca de exemplu
-binary.iso sau binary.img.
-
-_* *{Target distribution}*: Dea pe care se bazeaza sistemul live. Aceasta
-distributie poate fi diferita de cea a sistemului gazda.
-
-_* *{Squeeze/Wheezy/Sid (stable/testing/unstable)}*: Debian codenames for
-releases. At the time of writing, Squeeze is the current *{stable}* release
-and Wheezy is the current *{testing}* release. Sid will always be a synonym
-for the *{unstable}* release. Throughout the manual, we tend to use
-codenames for the releases, as that is what is supported by the tools
-themselves.
-
-*{stable}* contine ultima versiune oficiala a distributiei
-Debian. *{testing}* este sursa pentru urmatoarea versiune
-*{stable}*. Pricipalul avantaj la folosirea distibutiei *{testing}* este
-folosirea programelor mai noi decat cele din *{stable}*. Distributia
-*{unstable}* este locul unde au loc activ dezvoltarile din Debian. In
-general ea este folosita de dezvoltatori sau de cei ce le place riscul ... .
-
-2~ Autori
-
-Lista autorilor (in ordine alfabetica):
-
-_* Ben Armstrong
-
-_* Brendan Sleight
-
-_* Chris Lamb
-
-_* Daniel Baumann
-
-_* Franklin Piat
-
-_* Jonas Stein
-
-_* Kai Hendry
-
-_* Marco Amadori
-
-_* Mathieu Geli
-
-_* Matthias Kirschner
-
-_* Richard Nelson
-
-_* Trent W. Buck
-
-2~how-to-contribute Cum se poate contribui la acest document
-
-Acest manual este conceput ca un proiect comunitar si astfel orice
-propozitie sau inbunatatire sunt bune venite. Principala cale de a face o
-contributie este trimeterea unui mail la mailing list. Vedeti
-{Contact}#contact pentru mai multe informatii.
-
-In orice contributie trimisa va rog sa precizati in clar cine detine
-copyright-ul si sub ce licenta este publicata. A se nota ca o contrinutie
-este acceptata daca este licentiata in acceeasi termeni ca si restul
-documentului , adica GPL version 3 or later.
-
-Sursele acestui manual sunt gerate folosind Git version control
-system. Pute-ti checkout ultima copie prin executarea :
-
-code{
-
-$ git clone git://live.debian.net/git/live-manual.git
-
-}code
-
-Inainte de a trimite contibutia dvs, este de dorit sa efectuati o
-previzualizare a lucrarii. Pentru aceasta verifica-ti ca pachetele necesare
-pentru 'building' sunt instalate, prin executatea comenzii:
-
-code{
-
- # apt-get install make po4a sisu-complete libnokogiri-ruby
-
-}code
-
-Pute-ti crea live-manual de la nivelul de sus al directorului Git checkout
-al dvs, prin executatea:
-
-code{
-
- $ make build
-
-}code
-
-Since it takes a while to build the manual in all supported languages, you
-may find it convenient when proofing to build for only one language, e.g. by
-executing:
-
-code{
-
- $ make build LANGUAGES=en
-
-}code
-
-3~ Aplicarea de patch-uri
-
-Commiterea in direct este la indemana oricui. Totusi, va rugam sa trimeteti
-schimbarile mai mari , spre discutie , la mailing list. Pentru a fi trimise
-contibutiile la repository, pasii urmatori sunt necesari:
-
-_* Fetch the public commit key:
-
-code{
-
- $ mkdir -p ~/.ssh/identity.d
- $ wget http://live.debian.net/other/keys/git@live.debian.net \
- -O ~/.ssh/identity.d/git at live.debian.net
- $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
- -O ~/.ssh/identity.d/git at live.debian.net.pub
- $ chmod 0600 ~/.ssh/identity.d/git at live.debian.net*
-
-}code
-
-_* Adaugati urmatoarea sectiuna la openssh-client config:
-
-code{
-
- $ cat >> ~/.ssh/config << EOF
- Host live.debian.net
- Hostname live.debian.net
- User git
- IdentityFile ~/.ssh/identity.d/git at live.debian.net
- EOF
-
-}code
-
-_* Checkout un clon al manualului prin ssh:
-
-code{
-
- $ git clone gitosis at live.debian.net:/live-manual.git
- $ cd live-manual && git checkout debian-next
-
-}code
-
-_* Note that you should commit any changes on the debian-next branch, not on
-the debian branch.
-
-_* After editing the files in #{manual/en/}#, please call the 'commit'
-target in the top level directory to sanitize the files and update the
-translation files:
-
-code{
-
- $ make commit
-
-}code
-
-_* Dupa 'sanitizare' 'commit' schimbarile. Scrieti mesajele de commit, care
-constau in propozitii clare, care incep cu litere Mari, si se incheie cu
-punct si sens. Inceputul poate fii de forma
-'Fixing/Adding/Removing/Correcting/Translating':
-
-code{
-
- $ git commit -a -m "Adding a section on applying patches."
-
-}code
-
-_* Primite commit-ul la server:
-
-code{
-
- $ git push
-
-}code
-
-3~ Translation
-
-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.
-
-_* Once the new language is added, you can randomly start translating all po
-files in #{manual/po/}#.
-
-_* Don't forget you need #{make commit}# to ensure the translated manuals
-are updated from the po files, before #{git commit -a}# and #{git push}#.
diff --git a/manual/ro/about_project.ssi b/manual/ro/about_project.ssi
deleted file mode 100644
index 48b9a11..0000000
--- a/manual/ro/about_project.ssi
+++ /dev/null
@@ -1,110 +0,0 @@
-:B~ Despre Proiectul Debian Live
-
-1~about-project Despre Proiectul Debian Live
-
-2~ Motivatie
-
-3~ Ce nu e bine cu sistemele live actuale
-
-La momentul de inceput al proiectului Debian Live existau deja cateva
-sisteme Debian live si ele au depus o munca interesanta. Din perspectiva
-Debian marea majoritate a acestor sisteme au urmatoarele dezavantaje:
-
-_* They are not Debian projects and therefore lack support from within
-Debian.
-
-_* Ele amalgameaza diferite distributii, ca *{testing}* si *{unstable}*.
-
-_* Ele suporta doar arhitectura i386.
-
-_* Ele au modificat comportamentul si /sau aspectul programelor pentru a
-castuga spatiu.
-
-_* They include packages from outside of the Debian archive.
-
-_* Ele folosesc kernele modificate care contin patch-uri ce nu fac parte din
-Debian.
-
-_* Ele sunt greoaie si lente datorete marimii lor si deci inapropiate pentru
-situatii de salvare/rescue.
-
-_* Ele nu sunt disponibile in diferite sosuri ca CDs, DVDs, USB-stick si
-netboot images.
-
-3~ De ce e nevoie de propriul nostru sistem live ?
-
-Debian is the Universal Operating System: Debian has a live system to show
-around and to accurately represent the Debian system with the following main
-advantages:
-
-_* It would be a subproject of Debian.
-
-_* El reflecta starea (actuala) a distributiei.
-
-_* Se poate utiliza pe maximum de arhitecturi posibile.
-
-_* Contine doar programe Debian.
-
-_* It does not contain any packages that are not in the Debian archive.
-
-_* Foloseste un kernel Debian nealterat, fara patch-uri aditionale.
-
-2~ Filozofia
-
-3~ Only unchanged packages from Debian "main"
-
-We will only use packages from the Debian repository in the "main"
-section. The non-free section is not part of Debian and therefore cannot be
-used for official live system images.
-
-Nu vor fi facute nici o schimbare in programe. Daca este nevoie de acest
-lucru, schimbarile vor fi facute in coordonare cu responsabilul de program
-din Debian.
-
-Ca o exceptie, programele specifice ca live-boot, live-build sau live-config
-pot fi folosite temporar din depozitele proprii live, pentru nevoi de
-dezvoltare. (de exemplu pentru creerea de development snapshots). Acestea
-vor fi upload-ate in Debian la date cuvenite.
-
-3~ Nu vor fi programe de configurare pentru sistemul live.
-
-In aceasta faza nu vor fi propuse sau instalate example sau configuratii
-alternative. Toate programele sunt folosite cu configuratia default 'de
-baza', la fel ca in instalatia normaladin Debian.
-
-In caz de nevoie a unei configuratii diferite, aceasta schimbare va fii
-facuta in coordonare cu responsabilui de program din Debian.
-
-Cu toate acestea un sistem de configurare a programelor este permisa
-folosind debconf in #{lb config}# (use --preseed FILE), ce permite o
-particularizare a configurari programelor in sistemul live facur de dvs.,
-insa imaginile oficiale live doar configurari de baza vot fi
-folosite. Pentru mai multe informatii, urmariti {Customization
-overview}#customization-overview.
-
-Exceptie: Sunt desigur necesare cateva necesare sa aducem 'la viata' un
-sistem live ( de exemplu: configuratea pam care sa permita empty
-passwords). Dar aceste schimbari esentiale trebuie minimizate la maximum si
-pastrate in concordanta cu depozitul Debian.
-
-2~contact Contact
-
-_* *{Mailing list}*: Principalul mod de contact din proiect este mailing
-list la http://lists.debian.org/debian-live/.Va pute-ti adresa in direct
-prin mail la debian-live at lists.debian.org. Arhiva listei o gasi-ti la
-http://lists.debian.org/debian-live/.
-
-_* *{IRC}*: Un numar de utilizatori si dezvoltatori sunt prezenti in canalul
-#debian-live pe n irc.debian.org (OFTC). Daca aveti o intrebare pentru IRC ,
-fiti cu multa rabdare in asteptarea raspunsului. In caz de lipsa a unui
-raspuns , folositi mailing list.
-
-_* *{BTS}*: BTS adica Debian Bug Tracking System , contine detalii asupra
-rapoartelor de bug facute de utilizatorisau dezvoltatori. Fiecare bug are un
-numar, si este mentinut deschis pana la rezolvare. Alte informatii gasiti la
-{Reporting bugs}#bugs.
-
-_* *{Wiki}*: Debian Live are un wiki la http://wiki.debian.org/DebianLive ,
-si este locul unde pot fi gasite diferite informatii, se discuta modul de
-aplicare de tehnologii, sau sunt documentate alte lucrari legate de debian
-live si care pot depasi cadrul acestui document.
diff --git a/manual/ro/index.html.in b/manual/ro/index.html.in
deleted file mode 100644
index 223cfe0..0000000
--- a/manual/ro/index.html.in
+++ /dev/null
@@ -1,59 +0,0 @@
-<html>
-
-<head>
- <title>Debian Live Project</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-</head>
-
-<body>
- <h2>Debian Live Manual</h2>
-
- <p>
- Please report errors, omissions, patches and suggestions to our mailinglist
-at <a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>
-and read about <a href="html/about-manual.html#how-to-contribute">how to
-contribute</a> to the manual.
- </p>
-
- <h3>Available Formats</h3>
-
- <ul>
- <li><a href="epub/live-manual.epub">EPUB</a></li>
- <li>HTML: <a href="html/index.html">multi page</a>, <a
-href="html/live-manual.html">single page</a></li>
- <li><a href="odf/live-manual.odt">ODF</a></li>
- <li>PDF: <a href="pdf/live-manual.portrait-a4.pdf">A4 portrait</a>, <a
-href="pdf/live-manual.landscape-a4.pdf">A4 landscape</a>, <a
-href="pdf/live-manual.portrait-letter.pdf">letter portrait</a>, <a
-href="pdf/live-manual.landscape-letter.pdf">letter landscape</a></li>
- <li><a href="txt/live-manual.txt">Plain text</a></li>
- </ul>
-
- <p>
- Last changed: @DATE_CHANGE@<br />
- Last built: @DATE_BUILD@
- </p>
-
- <h3>Source</h3>
-
- <p>
- The sources for this manual is available in a <a
-href="http://git.or.cz/">Git</a> repository at live.debian.net.
- </p>
-
- <ul>
- <li>Browse: <a
-href="http://live.debian.net/gitweb/?p=live-manual.git"><small><tt>http://live.debian.net/gitweb/?p=live-manual.git</tt></small></a></li>
- <li>Git: <a
-href="git://live.debian.net/git/live-manual.git"><small><tt>git://live.debian.net/git/live-manual.git</tt></small></a></li>
- </ul>
-
- <p>
- <a href="http://live.debian.net/">Debian Live</a> <<a
-href="mailto:debian-live at lists.debian.org">debian-live at lists.debian.org</a>>
-- <a href="http://live.debian.net/legal.html">Legal Notice</a>
- </p>
-</body>
-
-</html>
diff --git a/manual/ro/live-manual.ssm b/manual/ro/live-manual.ssm
deleted file mode 100644
index f8faa5e..0000000
--- a/manual/ro/live-manual.ssm
+++ /dev/null
@@ -1,62 +0,0 @@
-% SiSU 2.0
-
- at title: Debian Live Manual
-
- at creator: Debian Live Project <debian-live at lists.debian.org>
-
- at rights:
- :copyright: Copyright (C) 2006-2011 Debian Live Project
- :license: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.<br><br>This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.<br><br>You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. <br><br>The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file.
-
- at date:
- :published: 2011-10-04
-
- at publisher: Debian Live Project <debian-live at lists.debian.org>
-
- at make:
- :bold: /Squeeze|squeeze|Wheezy|wheezy|Sid|sid/
- :italics: /live-boot|live-build|live-config|live-magic|live-manual|live-installer|debian-installer-launcher/
- :num_top: 1
- :skin: skin_debian-live
-
-:A~ @title
-
-:B~ About
-
-<< about_manual.ssi
-
-<< about_project.ssi
-
-:B~ User
-
-<< user_installation.ssi
-
-<< user_basics.ssi
-
-<< user_overview.ssi
-
-<< user_managing_a_configuration.ssi
-
-<< user_customization-overview.ssi
-
-<< user_customization-packages.ssi
-
-<< user_customization-contents.ssi
-
-<< user_customization-runtime.ssi
-
-<< user_customization-binary.ssi
-
-<< user_customization-installer.ssi
-
-:B~ Project
-
-<< project_bugs.ssi
-
-<< project_coding-style.ssi
-
-<< project_procedures.ssi
-
-:B~ Examples
-
-<< user_examples.ssi
diff --git a/manual/ro/project_bugs.ssi b/manual/ro/project_bugs.ssi
deleted file mode 100644
index b0c34fc..0000000
--- a/manual/ro/project_bugs.ssi
+++ /dev/null
@@ -1,198 +0,0 @@
-B~ Reporting bugs
-
-1~bugs Reporting bugs
-
-Debian Live is far from being perfect, but we want to make it as close as
-possible to perfect - with your help. Do not hesitate to report a bug: it is
-better to fill a report twice than never. However, this chapter includes
-recommendations how to file good bug reports.
-
-For the impatient:
-
-_* Always check first the image status updates on our homepage at
-http://live.debian.net/ for known issues.
-
-_* Always try to reproduce the bug with the *{most recent versions}* of
-live-build, live-boot, and live-config before submitting a bug report.
-
-_* Try to give *{as specific information as possible}* about the bug. This
-includes (at least) the version of live-build, live-boot, and live-config
-used and the distribution of the live system you are building.
-
-2~ Known issues
-
-Because Debian *{testing}* and Debian *{unstable}* distributions are a
-moving target, when you specify either as the target system distribution, a
-successful build may not always be possible.
-
-% FIXME:
-
-If this causes too much difficulty for you, do not build a system based on
-*{testing}* or *{unstable}*, but rather, use *{stable}*. live-build does
-always default to the *{stable}* release.
-
-Currently known issues are listed under the section 'status' on our homepage
-at http://live.debian.net/.
-
-It is out of the scope of this manual to train you to correctly identify and
-fix problems in packages of the development distributions, however, there
-are two things you can always try: If a build fails when the target
-distribution is *{testing}*, try *{unstable}*. If *{unstable}* does not work
-either, revert to *{testing}* and pin the newer version of the failing
-package from *{unstable}* (see {APT pinning}#apt-pinning for details).
-
-2~ Rebuild from scratch
-
-To ensure that a particular bug is not caused by an uncleanly built system,
-please always rebuild the whole live system from scratch to see if the bug
-is reproducible.
-
-2~ Use up-to-date packages
-
-Using outdated packages can cause significant problems when trying to
-reproduce (and ultimately fix) your problem. Make sure your build system is
-up-to-date and any packages included in your image are up-to-date as well.
-
-2~collect-information Collect information
-
-Please provide enough information with your report. At least include the
-exact version of live-build version where the bug is encountered and steps
-to reproduce it. Please use common sense and include other relevant
-information if you think that it might help in solving the problem.
-
-To make the most out of your bug report, we require at least the following
-information:
-
-_* Architecture of the host system
-
-_* Version of live-build on the host system
-
-_* Version of live-boot on the live system
-
-_* Version of live-config on the live system
-
-_* Version of #{debootstrap}# and/or #{cdebootstrap}# on the host system
-
-_* Architecture of the live system
-
-_* Distribution of the live system
-
-_* Version of the kernel on the live system
-
-You can generate a log of the build process by using the #{tee}# command. We
-recommend doing this automatically with an #{auto/build}# script; (see
-{Managing a configuration}#managing-a-configuration for details).
-
-code{
-
- # lb build 2>&1 | tee build.log
-
-}code
-
-At boot time, live-boot stores a log in #{/var/log/live.log}# (or
-#{/var/log/live-boot.log}#).
-
-Additionally, to rule out other errors, it is always a good idea to tar up
-your #{config/}# directory and upload it somewhere (do *{not}* send it as an
-attachment to the mailing list), so that we can try to reproduce the errors
-you encountered. If this is difficult (e.g. due to size) you can use the
-output of #{lb config --dump}# which produces a summary of your config tree
-(i.e. lists files in subdirectories of #{config/}# but does not include
-them).
-
-Remember to send in any logs that were produced with English locale
-settings, e.g. run your live-build commands with a leading #{LC_ALL=C}# or
-#{LC_ALL=en_US}#.
-
-2~ Isolate the failing case if possible
-
-If possible, isolate the failing case to the smallest possible change that
-breaks. It is not always easy to do this, so if you can't manage it for your
-report, don't worry. However, if you plan your development cycle well, using
-small enough change sets per iteration, you may be able to isolate the
-problem by constructing a simpler 'base' configuration that closely matches
-your actual configuration plus just the broken change set added to it. If
-you have a hard time sorting out which of your changes broke, it may be that
-you are including too much in each change set and should develop in smaller
-increments.
-
-2~ Use the correct package to report the bug against
-
-Where does the bug appear?
-
-3~ At build time whilst bootstrapping
-
-live-build first bootstraps a basic Debian system with #{debootstrap}# or
-#{cdebootstrap}#. Depending on the bootstrapping tool used and the Debian
-distribution it is bootstrapping, it may fail. If a bug appears here, check
-if the error is related to a specific Debian package (most likely), or if it
-is related to bootstrapping tool itself.
-
-In both cases, this is not a bug in Debian Live, but rather in Debian itself
-which we can not fix this directly. Please report such a bug against the
-bootstrapping tool or the failing package.
-
-3~ At build time whilst installing packages
-
-live-build installs additional packages from the Debian archive and
-depending on the Debian distribution used and the daily archive state, it
-can fail. If a bug appears here, check if the error is also reproducible on
-a normal system.
-
-If this is the case, this is not a bug in Debian Live, but rather in Debian
-- please report it against the failing package. Running #{debootstrap}#
-separately from the Live system build or running #{lb bootstrap --debug}#
-will give you more information.
-
-Also, if you are using a local mirror and/or any of sort of proxy and you
-are experiencing a problem, please always reproduce it first by
-bootstrapping from an official mirror.
-
-3~ At boot time
-
-If your image does not boot, please report it to the mailing list together
-with the information requested in {Collect
-information}#collect-information. Do not forget to mention, how/when the
-image failed, in Qemu, Virtualbox, VMWare or real hardware. If you are using
-a virtualization technology of any kind, please always run it on real
-hardware before reporting a bug. Providing a screenshot of the failure is
-also very helpful.
-
-3~ At run time
-
-If a package was successfully installed, but fails while actually running
-the Live system, this is probably a bug in Debian Live. However,
-
-2~ Do the research
-
-Before filing the bug, please search the web for the particular error
-message or symptom you are getting. As it is highly unlikely that you are
-the only person experiencing a particular problem, there is always a chance
-that it has been discussed elsewhere, and a possible solution, patch, or
-workaround has been proposed.
-
-You should pay particular attention to the Debian Live mailing list, as well
-as the homepage, as these are likely to contain the most up-to-date
-information. If such information exists, always include the references to it
-in your bug report.
-
-In addition, you should check the current bug lists for live-build,
-live-boot, and live-config to see whether something similar has been
-reported already.
-
-2~ Where to report bugs
-
-The Debian Live project keeps track of all bugs in the Debian Bug Tracking
-System (BTS). For information on how to use the system, please see
-http://bugs.debian.org/. You can also submit the bugs by using the
-#{reportbug}# command from the package with the same name.
-
-In general, you should report build time errors against the live-build
-package, boot time errors against live-boot, and run time errors against
-live-config. If you are unsure of which package is appropriate or need more
-help before submitting a bug report, please send a message to the mailing
-list and we will help you to figure it out.
-
-Please note that bugs found in distributions derived from Debian (such as
-Ubuntu and others) should *{not}* be reported to the Debian BTS unless they
-can be also reproduced on a Debian system using official Debian packages.
diff --git a/manual/ro/project_coding-style.ssi b/manual/ro/project_coding-style.ssi
deleted file mode 100644
index c4a9b86..0000000
--- a/manual/ro/project_coding-style.ssi
+++ /dev/null
@@ -1,144 +0,0 @@
-B~ Coding Style
-
-1~coding-style Coding Style
-
-This chapter documents the coding style used in live-boot and others.
-
-2~ Compatibility
-
-_* Don't use syntax or semantics that are unique to the Bash shell. For
-example, the use of array constructs.
-
-_* Only use the POSIX subset - for example, use $(foo) over `foo`.
-
-_* You can check your scripts with 'sh -n' and 'checkbashisms'.
-
-2~ Indenting
-
-_* Always use tabs over spaces.
-
-2~ Wrapping
-
-_* Generally, lines are 80 chars at maximum.
-
-_* Use the "Linux style" of line breaks:
-
-Bad:
-
-code{
-
- if foo; then
- bar
- fi
-
-}code
-
-Good:
-
-code{
-
- if foo
- then
- bar
- fi
-
-}code
-
-_* The same holds for functions:
-
-Bad:
-
-code{
-
- foo () {
- bar
- }
-
-}code
-
-Good:
-
-code{
-
- foo ()
- {
- bar
- }
-
-}code
-
-2~ Variables
-
-_* Variables are always in capital letters.
-
-_* Variables that used in #{lb config}# always start with #{LB_}# prefix.
-
-_* Internal temporary variables in live-build should start with the
-#{\_LB_}# prefix.
-
-_* Local variables start with live-build #{\_\_LB_}# prefix.
-
-_* Variables in connection to a boot parameter in live-config start with
-#{LIVE_}#.
-
-_* All other variables in live-config start with #{_}# prefix.
-
-_* Use braces around variables; e.g. write #{${FOO}}# instead of #{$FOO}#.
-
-_* Always protect variables with quotes to respect potential whitespaces:
-write #{"${FOO}"}# not #{${FOO}}#.
-
-_* For consistency reasons, always use quotes when assigning values to
-variables:
-
-Bad:
-
-code{
-
- FOO=bar
-
-}code
-
-Good:
-
-code{
-
- FOO="bar"
-
-}code
-
-_* If multiple variables are used, quote the full expression:
-
-Bad:
-
-code{
-
- if [ -f "${FOO}"/foo/"${BAR}"/bar ]
- then
- foobar
- fi
-
-}code
-
-Good:
-
-code{
-
- if [ -f "${FOO}/foo/${BAR}/bar" ]
- then
- foobar
- fi
-
-}code
-
-2~ Miscellaneous
-
-_* Use "#{|}#" (without the surround quotes) as a seperator in calls to sed,
-e.g. "#{sed -e 's|foo|bar|'}#" (without "").
-
-_* Don't use the #{test}# command for comparisons or tests, use "#{[}#"
-"#{]}#" (without ""); e.g. "#{if [ -x /bin/foo ]; ...}#" and not "#{if test
--x /bin/foo; ...}#".
-
-_* Use #{case}# wherever possible over #{test}#, as it's easier to read and
-faster in execution.
diff --git a/manual/ro/project_procedures.ssi b/manual/ro/project_procedures.ssi
deleted file mode 100644
index 49b1924..0000000
--- a/manual/ro/project_procedures.ssi
+++ /dev/null
@@ -1,139 +0,0 @@
-B~ Procedures
-
-1~procedures Procedures
-
-This chapter documents the procedures within the Debian Live project for
-various tasks that need cooperation with other teams in Debian.
-
-2~ Udeb Uploads
-
-Before commiting releases of a udeb in d-i svn, one has to call:
-
-code{
-
- $ ../../scripts/l10n/output-l10n-changes . -d
-
-}code
-
-2~ Major Releases
-
-Releasing a new stable major version of Debian includes a lot of different
-teams working together to make it happen. At some point, the Live team comes
-in and builds live system images. The requirements to do this are:
-
-_* A mirror containing the released versions for the debian, debian-security
-and debian-volatile archive which the debian-live buildd can access.
-
-_* The names of the image need to be known
-(e.g. debian-live-VERSION-ARCH-FLAVOUR.iso).
-
-_* The packagelists need to have been updated.
-
-_* The data from debian-cd needs to be synced (udeb exclude lists).
-
-_* The includes from debian-cd needs to be synced (README.*, doc/*, etc.).
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-2~ Point Releases
-
-_* Again, we need updated mirror of debian, debian-security and
-debian-volatile.
-
-_* Images are built and mirrored on cdimage.debian.org.
-
-_* Send announcement mail.
-
-3~ Point release announcement template
-
-An annoucement mail for point releases can be generated using the template
-below and the following command:
-
-code{
-
- $ sed \
- -e 's|%major%|5.0|g' \
- -e 's|%minor%|5.0.2|g' \
- -e 's|%codename%|lenny|g' \
- -e 's|%release_mail%|2009/msg00007.html|g'
-
-}code
-
-Please check the mail carefully before sending and pass it to others for
-proof-reading.
-
-code{
-
- Debian Live images for Debian GNU/Linux %major% updated
-
- The Debian Live project is pleased to announce the availability of
- updated Live images for its stable distribution Debian GNU/Linux %major%
- (codename "%codename%").
-
- The images are available for download at:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- This update incorporates the changes made in the %minor% point release,
- which adds corrections for security problems to the stable release
- along with a few adjustments for serious problems. A full list of the
- changes may be viewed at:
-
- <http://lists.debian.org/debian-announce/%release_mail%>
-
- It also includes the following Live-specific changes:
-
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [INSERT LIVE-SPECIFIC CHANGE HERE]
- * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
-
-
- URLs
- ----
-
- Download location of updated images:
-
- <http://cdimage.debian.org/cdimage/release/current-live/>
-
- Despre Proiectul Debian Live:
-
- <http://live.debian.net/>
-
- El reflecta starea (actuala) a distributiei:
-
- <http://ftp.debian.org/debian/dists/stable>
-
- stable distribution information (release notes, errata etc.):
-
- <http://www.debian.org/releases/stable/>
-
- Security announcements and information:
-
- <http://www.debian.org/security/>
-
-
- About Debian
- -------------
-
- The Debian Project is an association of Free Software developers who
- volunteer their time and effort in order to produce the completely free
- operating system Debian GNU/Linux.
-
-
- About Debian Live
- -----------------
-
- Debian Live is an official sub-project of Debian which produces Debian
- systems that do not require a classical installer. Images are available
- for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
- filesystem images for booting directly from the internet.
-
-
- Contact Information
- -------------------
-
- For further information, please visit the Debian Live web pages at
- <http://live.debian.net/> or alternatively send mail to
- <debian-live at lists.debian.org>.
-
-}code
diff --git a/manual/ro/user_basics.ssi b/manual/ro/user_basics.ssi
deleted file mode 100644
index 4429660..0000000
--- a/manual/ro/user_basics.ssi
+++ /dev/null
@@ -1,528 +0,0 @@
-:B~ The basics
-
-1~the-basics The basics
-
-This chapter contains a brief overview of the build process and instructions
-for using the three most commonly used image types. The most versatile image
-type, #{iso-hybrid}#, may be used on a virtual machine, optical media or USB
-portable storage device. In certain special cases, such as the use of
-persistence, #{usb-hdd}# may be more suitable for USB devices. The chapter
-finishes with instructions for building and using a #{net}# type image,
-which is a bit more involved due to the setup required on the server. This
-is a slightly advanced topic for anyone who is not familiar already with
-netbooting, but is included here because once the setup is done, it is a
-very convenient way to test and deploy images for booting on the local
-network without the hassle of dealing with image media.
-
-Throughout the chapter, we will often refer to the default filenames
-produced by live-build. If you are downloading a prebuilt image instead, the
-actual filenames may vary.
-
-2~what-is-live What is a live system?
-
-A live system usually means an operating system booted on a computer from a
-removable medium, such as a CD-ROM or USB stick, or from a network, ready to
-use without any installation on the usual drive(s), with auto-configuration
-done at run time (see {Terms}#terms).
-
-With Debian Live, it's a Debian GNU/Linux operating system, built for one of
-the supported architectures (currently amd64, i386, powerpc and sparc). It
-is made from the following parts:
-
-_* *{Linux kernel image}*, usually named #{vmlinuz*}#
-
-_* *{Initial RAM disk image (initrd)}*: a RAM disk set up for the Linux
-boot, containing modules possibly needed to mount the System image and some
-scripts to do it.
-
-_* *{System image}*: The operating system's filesystem image. Usually, a
-SquashFS compressed filesystem is used to minimize the Debian Live image
-size. Note that it is read-only. So, during boot the Debian Live system will
-use a RAM disk and 'union' mechanism to enable writing files within the
-running system. However, all modifications will be lost upon shutdown unless
-optional persistence is used (see {Persistence}#persistence).
-
-_* *{Bootloader}*: A small piece of code crafted to boot from the chosen
-media, possibly presenting a prompt or menu to allow selection of
-options/configuration. It loads the Linux kernel and its initrd to run with
-an associated system filesystem. Different solutions can be used, depending
-on the target media and format of the filesystem containing the previously
-mentioned components: isolinux to boot from a CD or DVD in ISO9660 format,
-syslinux for HDD or USB drive booting from a VFAT partition, extlinux for
-ext2/3/4 and btrfs partitions, pxelinux for PXE netboot, GRUB for ext2/3/4
-partitions, etc.
-
-You can use live-build to build the system image from your specifications,
-set up a Linux kernel, its initrd, and a bootloader to run them, all in one
-media-dependant format (ISO9660 image, disk image, etc.).
-
-2~building-iso-hybrid First steps: building an ISO hybrid image
-
-Regardless of the image type, you will need to perform the same basic steps
-to build an image each time. As a first example, execute the following
-sequence of live-build commands to create a basic ISO hybrid image
-containing just the Debian standard system without X.org. It is suitable for
-burning to CD or DVD media, and also to copy onto a USB stick.
-
-First, run the #{lb config}# command. This will create a "config/" hierarchy
-in the current directory for use by other commands:
-
-code{
-
- $ lb config
-
-}code
-
-No parameters are passed to #{lb config}#, so defaults for all of its
-various options will be used. See {The lb config command}#lb-config for more
-details.
-
-Now that the "config/" hierarchy exists, build the image with the #{lb
-build}# command:
-
-code{
-
- # lb build
-
-}code
-
-This process can take a while, depending on the speed of your network
-connection. When it is complete, there should be a #{binary-hybrid.iso}#
-image file, ready to use, in the current directory.
-
-2~using-iso-hybrid Using an ISO hybrid live image
-
-After either building or downloading an ISO hybrid image, which can be
-obtained at http://www.debian.org/CD/live/, the usual next step is to
-prepare your media for booting, either CD-R(W) or DVD-R(W) optical media or
-a USB stick.
-
-3~burning-iso-image Burning an ISO image to a physical medium
-
-Burning an ISO image is easy. Just install wodim and use it from the
-command-line to burn the image. For instance:
-
-code{
-
- # apt-get install wodim
-
- $ wodim binary-hybrid.iso
-
-}code
-
-3~copying-iso-hybrid-to-usb Copying an ISO hybrid image to a USB stick
-
-ISO images prepared with the #{isohybrid}# command, like the images produced
-by the default #{iso-hybrid}# binary image type, can be simply copied to a
-USB stick with the #{dd}# program or an equivalent. Plug in a USB stick with
-a size large enough for your image file and determine which device it is,
-which we hereafter refer to as #{${USBSTICK}}#. This is the device file of
-your key, such as #{/dev/sdb}#, not a partition, such as #{/dev/sdb1}#! You
-can find the right device name by looking in #{dmesg}#'s output after
-plugging in the stick, or better yet, #{ls -l /dev/disk/by-id}#.
-
-Once you are certain you have the correct device name, use the #{dd}#
-command to copy the image to the stick. *{This will definitely overwrite
-any previous contents on your stick!}*
-
-code{
-
- $ dd if=binary-hybrid.iso of=${USBSTICK}
-
-}code
-
-
-3~booting-live-media Booting the live media
-
-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.
-
-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.
-
-2~using-virtual-machine Using a virtual machine for testing
-
-It can be a great time-saver for the development of live images to run them
-in a virtual machine (VM). This is not without its caveats:
-
-_* Running a VM requires enough RAM for both the guest OS and the host and a
-CPU with hardware support for virtualization is recommended.
-
-_* There are some inherent limitations to running on a VM, e.g. poor video
-performance, limited choice of emulated hardware.
-
-_* When developing for specific hardware, there is no substitute for running
-on the hardware itself.
-
-_* Occasionally there are bugs that relate only to running in a VM. When in
-doubt, test your image directly on the hardware.
-
-Provided you can work within these constraints, survey the available VM
-software and choose one that is suitable for your needs.
-
-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.
-
-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{
-
- # apt-get install qemu-kvm qemu-utils
-
-}code
-
-Booting an ISO image is simple:
-
-code{
-
- $ kvm -cdrom binary-hybrid.iso
-
-}code
-
-See the man pages for more details.
-
-3~testing-iso-with-virtualbox Testing an ISO image with virtualbox-ose
-
-In order to test the ISO with #{virtualbox-ose}#:
-
-code{
-
- # apt-get install virtualbox-ose virtualbox-ose-dkms
-
- $ virtualbox
-
-}code
-
-Create a new virtual machine, change the storage settings to use
-#{binary-hybrid.iso}# as the CD/DVD device, and start the machine.
-
-Note: For live systems containing X.org that you want to test with
-#{virtualbox-ose}#, you may wish to include the VirtualBox X.org driver
-package, #{virtualbox-ose-guest-x11}#, in your live-build
-configuration. Otherwise, the resolution is limited to 800x600.
-
-code{
-
- $ lb config --packages virtualbox-ose-guest-x11
-
-}code
-
-2~building-usb-hdd Building a USB/HDD image
-
-Building a USB/HDD image is similar to ISO hybrid in all respects except you
-specify #{-b usb-hdd}# and the resulting filename is #{binary.img}# which
-cannot be burnt to optical media. It is suitable for booting from USB
-sticks, USB hard drives, and various other portable storage
-devices. Normally, an ISO hybrid image can be used for this purpose instead,
-but if you have a BIOS which does not handle hybrid images properly, or want
-to use the remaining space on the media for some purpose, such as a
-persistence partition, you need a USB/HDD image.
-
-Note: if you created an ISO hybrid image with the previous example, you will
-need to clean up your working directory with the #{lb clean}# command (see
-{The lb clean command}#lb-clean):
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as before, except this time specifying the
-USB/HDD image type:
-
-code{
-
- $ lb config -b usb-hdd
-
-}code
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-When the build finishes, a #{binary.img}# file should be present in the
-current directory.
-
-2~using-usb-hdd-image Using a USB/HDD image
-
-The generated binary image contains a VFAT partition and the syslinux
-bootloader, ready to be directly written on a USB stick. Since using a
-USB/HDD image is just like using an ISO hybrid image on USB, follow the
-instructions in {Using an ISO hybrid live image}#using-iso-hybrid, except
-use the filename #{binary.img}# instead of #{binary-hybrid.iso}#.
-
-3~testing-usb-hdd-with-qemu Testing a USB/HDD image with Qemu
-
-First, install QEMU as described above in {Testing an ISO image with
-QEMU}#testing-iso-with-qemu. Then run #{kvm}# or #{qemu}#, depending on
-which version your host system needs, specifying #{binary.img}# as the first
-hard drive.
-
-code{
-
- $ kvm -hda binary.img
-
-}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.
-
-code{
-
- # gparted ${USBSTICK}
-
-}code
-
-After the partition is created, where #{${PARTITION}}# is the name of the
-partition, such as #{/dev/sdb2}#, you have to create a filesystem on it. One
-possible choice would be ext4.
-
-code{
-
- # mkfs.ext4 ${PARTITION}
-
-}code
-
-Note: If you want to use the extra space with Windows, apparently that OS
-cannot normally access any partitions but the first. Some solutions to this
-problem have been discussed on our {mailing list}#contact, but it seems
-there are no easy answers.
-
-*{Remember: Every time you install a new binary.img on the stick, all data on the stick will be lost because the partition table is overwritten by the contents of the image, so back up your extra partition first to restore again after updating the live image.}*
-
-2~building-netboot-image Building a netboot image
-
-The following sequence of commands will create a basic netboot image
-containing the Debian standard system without X.org. It is suitable for
-booting over the network.
-
-Note: if you performed any previous examples, you will need to clean up your
-working directory with the #{lb clean}# command:
-
-code{
-
- # lb clean --binary
-
-}code
-
-Run the #{lb config}# command as follows to configure your image for
-netbooting:
-
-code{
-
- $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
-
-}code
-
-In contrast with the ISO and USB/HDD images, netbooting does not, itself,
-serve the filesystem image to the client, so the files must be served via
-NFS. The #{--net-root-path}# and #{--net-root-server}# options specify the
-location and server, respectively, of the NFS server where the filesytem
-image will be located at boot time. Make sure these are set to suitable
-values for your network and server.
-
-Now build the image with the #{lb build}# command:
-
-code{
-
- # lb build
-
-}code
-
-In a network boot, the client runs a small piece of software which usually
-resides on the EPROM of the Ethernet card. This program sends a DHCP request
-to get an IP address and information about what to do next. Typically, the
-next step is getting a higher level bootloader via the TFTP protocol. That
-could be pxelinux, GRUB, or even boot directly to an operating system like
-Linux.
-
-For example, if you unpack the generated #{binary-net.tar.gz}# archive in
-the #{/srv/debian-live}# directory, you'll find the filesystem image in
-#{live/filesystem.squashfs}# and the kernel, initrd and pxelinux bootloader
-in #{tftpboot/debian-live/i386}#.
-
-We must now configure three services on the server to enable netboot: the
-DHCP server, the TFTP server and the NFS server.
-
-3~ DHCP server
-
-We must configure our network's DHCP server to be sure to give an IP address
-to the netbooting client system, and to advertise the location of the PXE
-bootloader.
-
-Here is an example for inspiration, written for the ISC DHCP server
-#{isc-dhcp-server}# in the #{/etc/dhcp/dhcpd.conf}# configuration file:
-
-code{
-
- # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
-
- ddns-update-style none;
-
- option domain-name "example.org";
- option domain-name-servers ns1.example.org, ns2.example.org;
-
- default-lease-time 600;
- max-lease-time 7200;
-
- log-facility local7;
-
- subnet 192.168.0.0 netmask 255.255.255.0 {
- range 192.168.0.1 192.168.0.254;
- next-server servername;
- filename "pxelinux.0";
-}
-
-}code
-
-3~ TFTP server
-
-This serves the kernel and initial ramdisk to the system at run time.
-
-You should install the tftpd-hpa package. It can serve all files contained
-inside a root directory, usually #{/srv/tftp}#. To let it serve files inside
-#{/srv/debian-live/tftpboot}#, run as root the following command:
-
-code{
-
- # dpkg-reconfigure -plow tftpd-hpa
-
-}code
-
-and fill in the new tftp server directory when being asked about it.
-
-3~ NFS server
-
-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.
-
-Then, make the filesystem image available through NFS by adding a line like
-the following to #{/etc/exports}#:
-
-code{
-
- /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
-
-}code
-
-and tell the NFS server about this new export with the following command:
-
-code{
-
- # exportfs -rv
-
-}code
-
-Setting up these three services can be a little tricky. You might need some
-patience to get all of them working together. For more information, see the
-syslinux wiki at http://syslinux.zytor.com/wiki/index.php/PXELINUX or the
-Debian Installer Manual's TFTP Net Booting section at
-http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html. They might help,
-as their processes are very similar.
-
-3~ Netboot testing HowTo
-
-Netboot image creation is made easy with live-build magic, but testing the
-images on physical machines can be really time consuming.
-
-To make our life easier, we can use virtualization. There are two solutions.
-
-3~ Qemu
-
-_* Install #{qemu}#, #{bridge-utils}#, #{sudo}#.
-
-Edit #{/etc/qemu-ifup}#:
-
-code{
-
- #!/bin/sh
- sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
- echo "Executing /etc/qemu-ifup"
- echo "Bringing up $1 for bridged mode..."
- sudo /sbin/ifconfig $1 0.0.0.0 promisc up
- echo "Adding $1 to br0..."
- sudo /usr/sbin/brctl addif br0 $1
- sleep 2
-
-}code
-
-Get, or build a #{grub-floppy-netboot}# (in the svn).
-
-Launch #{qemu}# with "#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#"
-
-3~ VMWare Player
-
-_* Install VMWare Player ("free as in beer" edition)
-
-_* Create a PXETester directory, and create a text file called #{pxe.vwx}#
-inside
-
-_* Paste this text inside:
-
-code{
-
- #!/usr/bin/vmware
- config.version = "8"
- virtualHW.version = "4"
- memsize = "512"
- MemAllowAutoScaleDown = "FALSE"
-
- ide0:0.present = "FALSE"
- ide1:0.present = "FALSE"
- floppy0.present = "FALSE"
- sound.present = "FALSE"
- tools.remindInstall = "FALSE"
-
- ethernet0.present = "TRUE"
- ethernet0.addressType = "generated"
-
- displayName = "Test Boot PXE"
- guestOS = "other"
-
- ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
- uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
- ethernet0.generatedAddressOffset = "0"
-
-}code
-
-_* You can play with this configuration file (e.g. change memory limit to
-256)
-
-_* Double click on this file (or run VMWare player and select this file).
-
-_* When running just press space if that strange question comes up...
diff --git a/manual/ro/user_customization-binary.ssi b/manual/ro/user_customization-binary.ssi
deleted file mode 100644
index 6f843f8..0000000
--- a/manual/ro/user_customization-binary.ssi
+++ /dev/null
@@ -1,35 +0,0 @@
-B~ Customizing the binary image
-
-1~customizing-binary Customizing the binary image
-
-2~ Bootloader
-
-live-build uses syslinux as bootloader by default, which is by default
-configured to pause indefinitely at its splash screen. To adjust this, you
-can pass #{--syslinux-timeout TIMEOUT}# to #{lb config}#. The value is
-specified in units of seconds. A timeout of 0 (zero) disables the timeout
-completely. For more information please see syslinux(1).
-
-2~ ISO metadata
-
-When creating an ISO9660 binary image, you can use the following options to
-add various textual metadata for your image. This can help you easily
-identify the version or configuration of an image without booting it.
-
-_* #{LB_ISO_APPLICATION/--iso-application NAME}#: This should describe the
-application that will be on the image. The maximum length for this field is
-128 characters.
-
-_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: This should describe the
-preparer of the image, usually with some contact details. The default for
-this option is the live-build version you are using, which may help with
-debugging later. The maximum length for this field is 128 characters.
-
-_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: This should describe the
-publisher of the image, usually with some contact details. The maximum
-length for this field is 128 characters.
-
-_* #{LB_ISO_VOLUME/--iso-volume NAME}#: This should specify the volume ID of
-the image. This is used as a user-visible label on some platforms such as
-Windows and Apple Mac OS. The maximum length for this field is 32
-characters.
diff --git a/manual/ro/user_customization-contents.ssi b/manual/ro/user_customization-contents.ssi
deleted file mode 100644
index 814ba40..0000000
--- a/manual/ro/user_customization-contents.ssi
+++ /dev/null
@@ -1,154 +0,0 @@
-:B~ Customizing contents
-
-1~customizing-contents Customizing contents
-
-This chapter discusses fine-tuning customization of the live system contents
-beyond merely choosing which packages to include. Includes allow you to add
-or replace arbitrary files in your Debian Live image, hooks allow you to
-execute arbitrary commands at different stages of the build and at boot
-time, and preseeding allows you to configure packages when they are
-installed by supplying answers to debconf questions.
-
-2~ Includes
-
-While ideally a Debian live system would include files entirely provided by
-unmodified Debian packages, it is sometimes convenient to provide or modify
-some content by means of files. Using includes, it is possible to add (or
-replace) arbitrary files in your Debian Live image. live-build provides
-three mechanisms for using them:
-
-_* Chroot local includes: These allow you to add or replace files to the
-chroot/Live filesystem. Please see {Live/chroot local
-includes}#live-chroot-local-includes for more information.
-
-_* Binary local includes: These allow you to add or replace files in the
-binary image. Please see {Binary local includes}#binary-local-includes for
-more information.
-
-_* Binary includes: These allow you to add or replace Debian specific files
-in the binary image, such as the templates and tools directories. Please see
-{Binary includes}#binary-includes for more information.
-
-Please see {Terms}#terms for more information about the distinction between
-the "Live" and "binary" images.
-
-3~live-chroot-local-includes Live/chroot local includes
-
-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/chroot_local-includes}#
-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{
-
- $ mkdir -p config/chroot_local-includes/var/www
- $ cp /path/to/my/index.html config/chroot_local-includes/var/www
-
-}code
-
-Your configuration will then have the following layout:
-
-code{
-
- -- config
- [...]
- |-- chroot_local-includes
- | `-- var
- | `-- www
- | `-- index.html
- [...]
- `-- templates
-
-}code
-
-Chroot local includes are installed after package installation so that files
-installed by packages are overwritten.
-
-3~binary-local-includes Binary local includes
-
-To include material such as documentation or videos on the media filesystem
-so that it is accessible immediately upon insertion of the media without
-booting the Live system, you can use binary local includes. This works in a
-similar fashion to chroot local includes. For example, suppose the files
-#{~/video_demo.*}# are demo videos of the live system described by and
-linked to by an HTML index page. Simply copy the material to
-#{config/binary_local-includes/}# as follows:
-
-code{
-
- $ cp ~/video_demo.* config/binary_local-includes/
-
-}code
-
-These files will now appear in the root directory of the live media.
-
-3~binary-includes Binary includes
-
-live-build has some standard files (like documentation) that gets included
-in the default configuration on every live media. This can be disabled with:
-
-code{
-
- $ lb config --includes none
-
-}code
-
-Otherwise, the material will be installed by live-build in #{/includes/}# by
-default on the media filesystem, or else you can specify an alternate path
-with #{--includes}#.
-
-2~ Hooks
-
-Hooks allow commands to be performed in the chroot and binary stages of the
-build in order to customize the image.
-
-3~live-chroot-local-hooks Live/chroot local hooks
-
-To run commands in the chroot stage, create a hook script containing the
-commands in the #{config/chroot_local-hooks}# directory. The hook will run
-in the chroot after the rest of your chroot configuration has been applied,
-so remember to ensure your configuration includes all packages and files
-your hook needs in order to run. See the example chroot hook scripts for
-various common chroot customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-3~boot-time-hooks Boot-time hooks
-
-To execute commands at boot time, you can supply live-config hooks as
-explained in the "Customization" section of its man page. Examine
-live-config's own hooks provided in #{/lib/live/config/}#, noting the
-sequence numbers. Then provide your own hook prefixed with an appropriate
-sequence number, either as a chroot local include in
-#{config/chroot_local-includes/lib/live/config/}#, or as a custom package as
-discussed in {Installing modified or third-party
-packages}#installing-modified-or-third-party-packages.
-
-3~ Binary local hooks
-
-To run commands in the binary stage, create a hook script containing the
-commands in the #{config/binary_local-hooks}#. The hook will run after all
-other binary commands are run, but before binary_checksums, the very last
-binary commands The commands in your hook do not run in the chroot, so take
-care to not modify any files outside of the build tree, or you may damage
-your build system! See the example binary hook scripts for various common
-binary customization tasks provided in
-#{/usr/share/live/build/examples/hooks}# which you can copy or symlink to
-use them in your own configuration.
-
-2~ Preseeding Debconf questions
-
-Files in the #{config/chroot_local-preseed}# directory are considered to be
-debconf preseed files and are installed by live-build using
-#{debconf-set-selections}#.
-
-For more information about debconf, please see debconf(7) in the #{debconf}#
-package.
diff --git a/manual/ro/user_customization-installer.ssi b/manual/ro/user_customization-installer.ssi
deleted file mode 100644
index 9349f27..0000000
--- a/manual/ro/user_customization-installer.ssi
+++ /dev/null
@@ -1,88 +0,0 @@
-:B~ Customizing Debian Installer
-
-1~customizing-installer Customizing Debian Installer
-
-Debian Live system images can be integrated with Debian Installer. There are
-a number of different types of installation, varying in what is included and
-how the installer operates.
-
-Please note the careful use of capital letters when referring to the "Debian
-Installer" in this section - when used like this we refer explicitly to the
-official installer for the Debian system, not anything else. It is often
-seen abbreviated to "d-i".
-
-2~ Types of Debian Installer
-
-The three main types of installer are:
-
-*{"Regular" Debian Installer}*: This is a normal Debian Live image with a seperate kernel and initrd which (when selected from the appropriate bootloader) launches into a standard Debian Installer instance, just as if you had downloaded a CD image of Debian and booted it. Images containing a live system and such an otherwise independent installer are often referred to as "combined images".
-
-On such images, Debian is installed by fetching and installing .deb packages
-using #{debootstrap}# or #{cdebootstrap}#, from the local media or some
-network-based network, resulting in a standard Debian system being installed
-to the hard disk.
-
-This whole process can be preseeded and customized in a number of ways; see
-the relevant pages in the Debian Installer manual for more information. Once
-you have a working preseeding file, live-build can automatically put it in
-the image and enable it for you.
-
-*{"Live" Debian Installer}*: This is a Debian Live image with a separate kernel and initrd which (when selected from the appropriate bootloader) launches into an instance of the Debian Installer.
-
-Installation will proceed in an identical fashion to the "Regular"
-installation described above, but at the actual package installation stage,
-instead of using #{debootstrap}# to fetch and install packages, the live
-filesystem image is copied to the target. This is achieved with a special
-udeb called live-installer.
-
-After this stage, the Debian Installer continues as normal, installing and
-configuring items such as bootloaders and local users, etc.
-
-Note: to support both normal and live installer entries in the bootloader of
-the same live media, you must disable live-installer by preseeding
-#{live-installer/enable=false}#.
-
-*{"Desktop" Debian Installer}*: Regardless of the type of Debian Installer included, #{d-i}# can be launched from the Desktop by clicking on an icon. This is user friendlier in some situations. In order to make use of this, the debian-installer-launcher package needs to be included.
-
-Note that by default, live-build does not include Debian Installer images in
-the images, it needs to be specifically enabled with #{lb config}#. Also,
-please note that for the "Desktop" installer to work, the kernel of the live
-system must match the kernel #{d-i}# uses for the specified
-architecture. For example:
-
-code{
-
- $ lb config --architecture i386 --linux-flavours 486 \
- --debian-installer live --packages debian-installer-launcher
-
-}code
-
-2~ Customizing Debian Installer by preseeding
-
-As described in the Debian Installer Manual, Appendix B at
-http://www.debian.org/releases/stable/i386/apb.html, "Preseeding provides a
-way to set answers to questions asked during the installation process,
-without having to manually enter the answers while the installation is
-running. This makes it possible to fully automate most types of installation
-and even offers some features not available during normal installations."
-This kind of customization is best accomplished with live-build by placing
-the configuration in a #{preseed.cfg}# file included in
-#{config/binary_debian-installer/}#. For example, to preseed setting the
-locale to #{en_US}#:
-
-code{
-
- $ echo "d-i debian-installer/locale string en_US" \
- >> config/binary_debian-installer/preseed.cfg
-
-}code
-
-2~ Customizing Debian Installer content
-
-For experimental or debugging purposes, you might want to include locally
-built #{d-i}# component udeb packages. Place these in
-#{config/binary_local-udebs/}# to include them in the image. Additional or
-replacement files and directories may be included in the installer initrd as
-well, in a similar fashion to {Live/chroot local
-includes}#live-chroot-local-includes, by placing the material in
-#{config/binary_debian-installer-includes/}#.
diff --git a/manual/ro/user_customization-overview.ssi b/manual/ro/user_customization-overview.ssi
deleted file mode 100644
index 137e322..0000000
--- a/manual/ro/user_customization-overview.ssi
+++ /dev/null
@@ -1,76 +0,0 @@
-:B~ Customizing contents
-
-1~customization-overview Customization overview
-
-This chapter gives an overview of the various ways in which you may
-customize a Debian Live system.
-
-2~ Build time vs. boot time configuration
-
-Live system configuration options are divided into build-time options which
-are options that are applied at build time and boot-time options which are
-applied at boot time. Boot-time options are further divided into those
-occurring early in the boot, applied by the live-boot package, and those
-that happen later in the boot, applied by live-config. Any boot-time option
-may be modified by the user by specifying it at the boot prompt. The image
-may also be built with default boot parameters so users can normally just
-boot directly to the live system without specifying any options when all of
-the defaults are suitable. In particular, the argument to #{lb
---bootappend-live}# consists of any default kernel command line options for
-the Live system, such as persistence, keyboard layouts, or timezone. See
-{Customizing locale and language}#customizing-locale-and-language, for
-example.
-
-Build-time configuration options are described in the #{lb config}# man
-page. Boot-time options are described in the man pages for live-boot and
-live-config. Although the live-boot and live-config packages are installed
-within the live system you are building, it is recommended that you also
-install them on your build system for easy reference when you are working on
-your configuration. It is safe to do so, as none of the scripts contained
-within them are executed unless the system is configured as a live system.
-
-2~stages-of-the-build Stages of the build
-
-The build process is divided into stages, with various customizations
-applied in sequence in each. The first stage to run is the *{bootstrap}*
-stage. This is the initial phase of populating the chroot directory with
-packages to make a barebones Debian system. This is followed by the
-*{chroot}* stage, which completes the construction of chroot directory,
-populating it with all of the packages listed in the configuration, along
-with any other materials. Most customization of content occurs in this
-stage. The final stage of preparing the live image is the *{binary}* stage,
-which builds a bootable image, using the contents of the chroot directory to
-construct the root filesystem for the Live system, and including the
-installer and any other additional material on the target media outside of
-the Live system's filesystem. After the live image is built, if enabled, the
-source tarball is built in the *{source}* stage.
-
-Within each of these stages, there is a particular sequence in which
-commands are applied. These are arranged in such a way as to ensure
-customizations can be layered in a reasonable fashion. For example, within
-the *{chroot}* stage, preseeds are applied before any packages are
-installed, packages are installed before any locally included files or
-patches are applied, and hooks are run later, after all of the materials are
-in place.
-
-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.
-
-2~ Customization tasks
-
-The following chapters are organized by the kinds of customization task
-users typically perform: {Customizing package
-installation}#customizing-package-installation, {Customizing
-contents}#customizing-contents and {Customizing locale and
-language}#customizing-locale-and-language cover just a few of the things you
-might want to do.
diff --git a/manual/ro/user_customization-packages.ssi b/manual/ro/user_customization-packages.ssi
deleted file mode 100644
index 6b6f4fa..0000000
--- a/manual/ro/user_customization-packages.ssi
+++ /dev/null
@@ -1,586 +0,0 @@
-:B~ Customizing package installation
-
-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.
-
-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 #{squeeze}# for the Squeeze 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{
-
- $ lb config --distribution sid
-
-}code
-
-Within the distribution archive, archive areas are major divisions of the
-archive. In Debian, these are #{main}#, #{contrib}# and #{non-free}#. Only
-#{main}# contains software that is part of the Debian distribution, hence
-that is the default. One or more values may be specified, e.g.
-
-code{
-
- $ lb config --archive-areas "main contrib"
-
-}code
-
-Experimental support is available for some Debian derivatives through a
-#{--mode}# option. By default, this option is set to #{debian}#, even if you
-are building on a non-Debian system. If you specify #{--mode ubuntu}# or
-#{--mode emdebian}#, the distribution names and archive areas for the
-specified derivative are supported instead of the ones for Debian. The mode
-also modifies live-build behaviour to suit the derivatives.
-
-*{Note:}* The projects for whom these modes were added are primarily responsible for supporting users of these options. The Debian live project, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
-
-3~ Distribution mirrors
-
-The Debian archive is replicated across a large network of mirrors around
-the world so that people in each region can choose a nearby mirror for best
-download speed. Each of the #{--mirror-*}# options governs which
-distribution mirror is used at various stages of the build. Recall from
-{Stages of the build}#stages-of-the-build that the *bootstrap* stage is when
-the chroot is initially populated by debootstrap with a minimal system, and
-the *chroot* stage is when the chroot used to construct the live system's
-filesystem is built. Thus, the corresponding mirror switches are used for
-those stages, and later, in the *binary* stage, the #{--mirror-binary}# and
-#{--mirror-binary-security}# values are used, superceding any mirrors used
-in an earlier stage.
-
-3~distribution-mirrors-build-time Distribution mirrors used at build time
-
-To set the distribution mirrors used at build time to point at a local
-mirror, it is sufficient to set #{--mirror-bootstrap}# and
-#{--mirror-chroot-security}# as follows.
-
-code{
-
- $ lb config --mirror-bootstrap http://localhost/debian/ \
- --mirror-chroot-security http://localhost/debian-security/
-
-}code
-
-The chroot mirror, specified by #{--mirror-chroot}#, defaults to the
-#{--mirror-bootstrap}# value.
-
-3~ Distribution mirrors used at run time
-
-The #{--mirror-binary*}# options govern the distribution mirrors placed in
-the binary image. These may be used to install additional packages while
-running the live system. The defaults employ #{cdn.debian.net}#, a service
-that chooses a geographically close mirror based on the user's IP
-number. This is a suitable choice when you cannot predict which mirror will
-be best for all of your users. Or you may specify your own values as shown
-in the example below. An image built from this configuration would only be
-suitable for users on a network where "#{mirror}#" is reachable.
-
-code{
-
- $ lb config --mirror-binary http://mirror/debian/ \
- --mirror-binary-security http://mirror/debian-security/
-
-}code
-
-3~additional-repositories Additional repositories
-
-You may add more repositories, broadening your package choices beyond what
-is available in your target distribution. These may be, for example, for
-backports, experimental or custom packages. To configure additional
-repositories, create #{config/chroot_sources/your-repository.chroot}#,
-and/or #{config/chroot_sources/your-repository.binary}# files. As with the
-#{--mirror-*}# options, these govern the repositories used in the *chroot*
-stage when building the image, and in the *binary* stage, i.e. for use when
-running the live system.
-
-For example, #{config/chroot_sources/live.chroot}# allows you to install
-packages from the debian live snapshot repository at live system build time.
-
-code{
-
- deb http://live.debian.net/ sid-snapshots main contrib non-free
-
-}code
-
-If you add the same line to #{config/chroot_sources/live.binary}#, the
-repository will be added to your live system's #{/etc/apt/sources.list.d/}#
-directory.
-
-If such files exist, they will be picked up automatically.
-
-You should also put the GPG key used to sign the repository into
-#{config/chroot_sources/your-repository.{binary,chroot}.gpg}# files.
-
-*{Note:}* some preconfigured package repositories are available for easy selection through the #{--repository}# option, e.g. for enabling live snapshots, a simple command is enough to enable it:
-
-code{
-
- $ lb config --repository live.debian.net
-
-}code
-
-2~choosing-packages-to-install Choosing packages to install
-
-There are a number of ways to choose which packages live-build will install
-in your image, covering a variety of different needs. You can simply name
-individual packages to install, either with the #{--packages}# option for a
-few packages, or in a package list of your own for larger numbers. You can
-also choose larger predefined lists of packages, or use APT tasks. And
-finally, you may place package files in your #{config/}# tree, which is well
-suited to testing of new or experimental packages before they are available
-from a repository.
-
-3~ Choosing a few packages
-
-When the number of packages added is small, simply specify
-#{--packages}#. For example:
-
-code{
-
- $ lb config --packages "package1 package2 package3"
-
-}code
-
-The behaviour of live-build when specifying a package that does not exist is
-determined by your choice of APT utility. See {Choosing apt or
-aptitude}#choosing-apt-or-aptitude for more details.
-
-If you need to specify a large number of packages to be installed or you
-need flexibility regarding which packages to install, use package lists as
-discussed in the following section, {Package lists}#package-lists.
-
-3~package-lists Package lists
-
-Package lists are a powerful way of expressing which packages should be
-installed. The list syntax supports included files and conditional sections
-which makes it easy to build lists from other lists and adapt them for use
-in multiple configurations. You can use predefined package lists, providing
-in a modular fashion package selections from each of the major desktop
-environments and some special purpose lists, as well as standard lists the
-others are based upon. You can also provide your own package lists, or use a
-combination of both.
-
-3~ Predefined package lists
-
-The simplest way to use lists is to specify one or more predefined lists
-with the #{--packages-lists}# option. For example:
-
-code{
-
- $ lb config --packages-lists "gnome-core rescue"
-
-}code
-
-In addition to these lists, live-build supports four virtual package lists:
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#,
-each of which provide a more extensive selection of packages that
-corresponds with Debian Installer defaults for these desktop
-environments. See {Desktop and language tasks}#desktop-and-language-tasks
-for more details.
-
-*{Note:}* The prebuilt GNOME, KDE, LXDE and XFCE images available for download at http://live.debian.net are built using the corresponding virtual #{*-desktop}# lists.
-
-The default location for the list files on your system is
-#{/usr/share/live/build/lists/}#. To determine the packages in a given list,
-read the corresponding file, paying attention to included files and
-conditionals as described in the following sections.
-
-3~ Local package lists
-
-You may supplement or replace entirely the supplied lists using local
-package lists stored in #{config/chroot_local-packageslists/}#.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed. Local package lists always override package lists
-distributed with live-build. This can cause undesired effects, we therefore
-recommend to use unique names for local package lists.
-
-3~ Local binary package lists
-
-In case you want to include some required .deb packages to live media's
-#{pool/}# (without installing them onto the live image) you may need to use
-lists using binary local package lists stored in
-#{config/binary_local-packageslists/}#. Such media can be used as a
-customized Debian install image for offline installations.
-
-Package lists that exist in this directory need to have a #{.list}# suffix
-in order to be processed.
-
-3~ Extending a provided package list using includes
-
-The package lists that are included with live-build make extensive use of
-includes. Refer to these in the #{/usr/share/live/build/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/chroot_local-packageslists/mygnome.list}# with
-the following contents:
-
-code{
-
- #include <gnome>
- iceweasel
-
-}code
-
-3~ Using conditionals inside package lists
-
-Any of the live-build configuration variables stored in #{config/*}# (minus
-the #{LB_}# prefix) may be used in conditional statements in package
-lists. Generally, this means any #{lb config}# option uppercased and with
-dashes changed to underscores. But in practice, it is only the ones that
-influence package selection that make sense, such as #{DISTRIBUTION}#,
-#{ARCHITECTURE}# or #{ARCHIVE_AREAS}#.
-
-For example, to install #{ia32-libs}# if the #{--architecture amd64}# is
-specified:
-
-code{
-
- #if ARCHITECTURE amd64
- ia32-libs
- #endif
-
-}code
-
-You may test for any one of a number of values, e.g. to install
-#{memtest86+}# if either #{--architecture i386}# or #{--architecture amd64}#
-is specified:
-
-code{
-
- #if ARCHITECTURE i386 amd64
- memtest86+
- #endif
-
-}code
-
-You may also test against variables that may contain more than one value,
-e.g. to install #{vrms}# if either #{contrib}# or #{non-free}# is specified
-via #{--archive-areas}#:
-
-code{
-
- #if ARCHIVE_AREAS contrib non-free
- vrms
- #endif
-
-}code
-
-A conditional may surround an #{#include}# directive:
-
-code{
-
- #if ARCHITECTURE amd64
- #include <gnome-full>
- #endif
-
-}code
-
-The nesting of conditionals is not supported.
-
-3~ Tasks
-
-The Debian Installer offers the user choices of a number of preselected
-lists of packages, each one focused on a particular kind of system, or task
-a system may be used for, such as "Graphical desktop environment", "Mail
-server" or "Laptop". These lists are called "tasks" and are supported by APT
-through the "Task:" field. You can specify one or more tasks in live-build
-via the #{--tasks}# option, as in the example below.
-
-code{
-
- $ lb config --tasks "mail-server file-server"
-
-}code
-
-The primary tasks available in the Debian Installer can be listed with
-#{tasksel --list-tasks}# in the live system. The contents of any task,
-including ones not included in this list, may be examined with #{tasksel
---task-packages}#.
-
-3~desktop-and-language-tasks Desktop and language tasks
-
-Desktop and language tasks are special cases. In the Debian Installer, if
-the medium was prepared for a particular desktop environment flavour, the
-corresponding task will be automatically installed. Thus, there are
-#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}#
-tasks, none of which are offered in #{tasksel}#'s menu. Likewise, there are
-no menu entries for tasks for languages, but the user's language choice
-during the install influences the selection of corresponding language tasks.
-
-In live-build, therefore, these special cases are also given special
-consideration, but with three notable differences at the time of writing.
-
-First, there is no provision made yet automatically for language tasks,
-although a subset of those packages are included if you specify #{lb config
---language}#. If you need those tasks, which include such things as
-language-specific fonts and input-method packages, you need to specify them
-in your configuration. For example:
-
-code{
-
- $ lb config --tasks "japanese japanese-desktop japanese-gnome-desktop"
-
-}code
-
-Second, live-build supports #{*-desktop}# virtual package lists for each of
-the desktop flavours mentioned above, which select the #{standard-x11}#
-predefined package list, the corresponding #{*-desktop}# task and three
-additional tasks: #{desktop}#, #{standard}# and #{laptop}#. So, for example,
-if you specify #{--packages-lists gnome-desktop}#, it is equivalent to
-specifying #{--packages debian-installer-launcher --packages-lists
-standard-x11 --tasks "gnome-desktop desktop standard laptop"}#.
-
-Third, if any of the tasks for these desktop flavours are selected, either
-explicitly through #{--tasks}# or implicitly by #{--packages-lists}#,
-live-build will preseed the corresponding desktop value for Debian Installer
-(if it is included) to ensure it follows its own rules for installing
-different desktop flavours.
-
-*{Note:}* There is also an experimental #{--language}# option that has an overlapping purpose with language tasks. For any language for which it is known that there are #{*-l10n}# packages, if #{--language}# is specified, those packages will be installed. Furthermore, if any #{syslinux}# templates matching the language are found, they will be used instead of the default English templates. The package selection done by #{--language}# is a poor approximation of language tasks, as it requires that the list of packages to include per language be maintained internally in live-build, and besides, language tasks are more comprehensive and flexible. However, the #{syslinux}# aspect is still useful. Thus, if you use #{--bootloader syslinux}# and templates for the specified language exist either in #{/usr/share/live/build/templates/syslinux/}# or #{config/templates/syslinux/}#, consider using this option, possibly in combination with tasks to ensure all relevant packages are installed
. For example:
-
-code{
-
- $ lb config --language es
-
-}code
-
-Even so, it is limited in that it only supports a single language and a
-single bootloader. Therefore, for all of these reasons, the future of this
-option is under review, possibly to be replaced with something entirely
-different in the next major release of live-build.
-
-2~installing-modified-or-third-party-packages Installing modified or
-third-party packages
-
-Whilst it is against the philosophy of Debian Live, it may sometimes be
-necessary to build a Live system with modified versions of packages that are
-in the Debian repository. This may be to modify or support additional
-features, languages and branding, or even to remove elements of existing
-packages that are undesirable. Similarly, "third-party" packages may be used
-to add bespoke and/or proprietary functionality.
-
-This section does not cover advice regarding building or maintaining
-modified packages. Joachim Breitner's 'How to fork privately' method from
-http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
-may be of interest, however. The creation of bespoke packages is covered in
-the Debian New Maintainers' Guide at http://www.debian.org/doc/maint-guide/
-and elsewhere.
-
-There are two ways of installing modified custom packages:
-
-_* #{chroot_local-packages}#
-
-_* Using a custom APT repository
-
-Using #{chroot_local-packages}# is simpler to achieve and useful for
-"one-off" customizations but has a number of drawbacks, whilst using a
-custom APT repository is more time-consuming to set up.
-
-3~ Using #{chroot_local-packages}# to install custom packages
-
-To install a custom package, simply copy it to the
-#{config/chroot_local-packages/}# directory. Packages that are inside this
-directory will be automatically installed into the live system during build
-- you do not need to specify them elsewhere.
-
-Packages *{must}* be named in the prescribed way. One simple way to do this
-is to use #{dpkg-name}#.
-
-Using #{chroot_local-packages}# for installation of custom packages has
-disadvantages:
-
-_* It is not possible to use secure APT.
-
-_* You must install all appropriate packages in the
-#{config/chroot_local-packages/}# directory.
-
-_* It does not lend itself to storing Debian Live configurations in revision
-control.
-
-3~ Using an APT repository to install custom packages
-
-Unlike using #{chroot_local-packages}#, when using a custom APT repository
-you must ensure that you specify the packages elsewhere. See {Choosing
-packages to install}#choosing-packages-to-install for details.
-
-Whilst it may seem unnecessary effort to create an APT repository to install
-custom packages, the infrastructure can be easily re-used at a later date to
-offer updates of the modified packages.
-
-3~ Custom packages and APT
-
-live-build uses APT to install all packages into the live system so will
-therefore inherit behaviours from this program. One relevant example is that
-(assuming a default configuration) given a package available in two
-different repositories with different version numbers, APT will elect to
-install the package with the higher version number.
-
-Because of this, you may wish to increment the version number in your custom
-packages' #{debian/changelog}# files to ensure that your modified version is
-installed over one in the official Debian repositories. This may also be
-achieved by altering the live system's APT pinning preferences - see {APT
-pinning}#apt-pinning for more information.
-
-2~ Configuring APT at build time
-
-You can configure APT through a number of options applied only at build
-time. (APT configuration used in the running live system may be configured
-in the normal way for live system contents, that is, by including the
-appropriate configurations through #{config/chroot_local_includes/}#.) For a
-complete list, look for options starting with #{apt}# in the #{lb_config}#
-man page.
-
-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.
-
-_* #{apt}#: With this method, if a missing package is specified, the package
-installation will fail. This is the default setting.
-
-_* #{aptitude}#: With this method, if a missing package is specified, the
-package installation will succeed.
-
-3~ Using a proxy with APT
-
-One commonly required APT configuration is to deal with building an image
-behind a proxy. You may specify your APT proxy with the #{--apt-ftp-proxy}#
-or #{--apt-http-proxy}# options as needed, e.g.
-
-code{
-
- $ lb config --apt-http-proxy http://proxy/
-
-}code
-
-3~ Tweaking APT to save space
-
-You may find yourself needing to save some space on the image media, in
-which case one or the other or both of the following options may be of
-interest.
-
-If you don't want to include APT indices in the image, you can omit those
-with:
-
-code{
-
- $ lb config --binary-indices false
-
-}code
-
-This will not influence the entries in /etc/apt/sources.list, but merely
-whether /var/lib/apt contains the indices files or not. The tradeoff is that
-APT needs those indices in order to operate in the live system, so before
-performing #{apt-cache search}# or #{apt-get install}#, for instance, the
-user must #{apt-get update}# first to create those indices.
-
-If you find the installation of recommended packages bloats your image too
-much, you may disable that default option of APT with:
-
-code{
-
- $ lb config --apt-recommends false
-
-}code
-
-The tradeoff here is that if you don't install recommended packages for a
-given package, that is, "packages that would be found together with this one
-in all but unusual installations" (Debian Policy Manual, section 7.2), some
-packages that you actually need may be omitted. Therefore, we suggest you
-review the difference turning off recommends makes to your packages list
-(see the #{binary.packages}# file generated by #{lb build}#) and re-include
-in your list any missing packages that you still want
-installed. Alternatively, if you find you only want a small number of
-recommended packages left out, leave recommends enabled and set a negative
-APT pin priority on selected packages to prevent them from being installed,
-as explained in {APT pinning}#apt-pinning.
-
-3~ Passing options to apt or aptitude
-
-If there is not an #{lb config}# option to alter APT's behaviour in the way
-you need, use #{--apt-options}# or #{--aptitude-options}# to pass any
-options through to your configured APT tool. See the man pages for #{apt}#
-and #{aptitude}# for details.
-
-3~apt-pinning APT pinning
-
-For background, please first read the #{apt_preferences(5)}# man page. APT
-pinning can be configured either for build time, or else for run time. For
-the former, create #{config/chroot_apt/preferences}#. For the latter, create
-#{config/chroot_local-includes/etc/apt/preferences}#.
-
-Let's say you are building a Squeeze live system but need all the live
-packages that end up in the binary image to be installed from Sid at build
-time. You need to add Sid to your APT sources and pin it so that only the
-packages you want are installed from it at build time and all others are
-taken from the target system distribution, Squeeze. The following will
-accomplish this:
-
-code{
-
- $ echo "deb http://mirror/debian sid main" > config/chroot_sources/sid.chroot
- $ cat >>config/chroot_apt/preferences <<END
- Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
- Pin: release n=sid
- Pin-Priority: 600
-
- Package: *
- Pin: release n=sid
- Pin-Priority: 1
- END
-
-}code
-
-*{Note:}* Wildcards can be used in package names (e.g. *{Package: live-*}*) with Apt version 0.8.14 or higher. This means that it works with Wheezy using:
-
-code{
-
-$ 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 #{--packages-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{
-
- Package: gnome-keyring
- Pin: version *
- Pin-Priority: -1
-
-}code
diff --git a/manual/ro/user_customization-runtime.ssi b/manual/ro/user_customization-runtime.ssi
deleted file mode 100644
index 4bbf347..0000000
--- a/manual/ro/user_customization-runtime.ssi
+++ /dev/null
@@ -1,229 +0,0 @@
-:B~ Customizing run time behaviours
-
-1~customizing-run-time-behaviours Customizing run time behaviours
-
-All configuration that is done during run time is done by live-config. Here
-are some of the most common options of live-config that users are interested
-in. A full list of all possibilities can be found in the manpage of
-live-config.
-
-2~ Customizing the live user
-
-One important consideration is that the live user is created by live-boot at
-boot time, not by live-build at build time. This not only influences where
-materials relating to the live user are introduced in your build, as
-discussed in {Live/chroot local includes}#live-chroot-local-includes, but
-also any groups and permissions associated with the live user.
-
-You can specify additional groups that the live user will belong to by
-preseeding the #{passwd/user-default-groups}# debconf value. For example, to
-add the live user to the #{fuse}# group, add the following to a file in the
-#{config/chroot_local-preseed}# directory:
-
-code{
-
- user-setup passwd/user-default-groups string audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse
-
-}code
-
-It is also possible to change the default username "user" and the default
-password "live". If you want to do that for any reason, you can easily
-achieve it as follows:
-
-To change the default username you can simply specify it in your config:
-
-code{
-
-$ lb config --bootappend-live "username=live-user"
-
-}code
-
-One possible way of changing the default password is by means of a hook as
-described in {Boot-time hooks}#boot-time-hooks. In order to do that you can
-use the "passwd" hook from #{/usr/share/doc/live-config/examples/hooks}#,
-prefix it accordingly (e.g. 200-passwd) and add it to
-#{config/chroot_local-includes/lib/live/config/}#
-
-2~customizing-locale-and-language Customizing locale and language
-
-When the live system boots, language is involved in three steps:
-
-_* the locale generation
-
-_* setting the keyboard layout for the console
-
-_* setting the keyboard layout for X
-
-The default locale when building a Live system is "locales=en_US.UTF-8". To
-define the locale that should be generated, use the #{locales}# parameter in
-the #{--bootappend-live}# option of #{lb config}#, e.g.
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8"
-
-}code
-
-This parameter can also be used at the kernel command line. You can specify
-a locale by a full #{language_country.encoding}# word.
-
-Both the console and X keyboard configuration depend on the
-#{keyboard-layouts}# parameter of the #{--bootappend-live}# option. Valid
-options for X keyboard layouts can be found in
-#{/usr/share/X11/xkb/rules/base.xml}# (rather limited to two-letters country
-codes). To find the value (the two characters) corresponding to a language
-try searching for the english name of the nation where the language is
-spoken, e.g:
-
-code{
-
- $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
- <name>se</name>
-
-}code
-
-To get the locale files for German and Swiss German keyboard layout in X
-use:
-
-code{
-
- $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"
-
-}code
-
-A list of the valid values of the keyboards for the console can be figured
-with the following command:
-
-code{
-
- $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
- do basename $i | head -c -9; echo; done | sort | less
-
-}code
-
-Alternatively, you can use the #{console-setup}# package, a tool to let you
-configure console layout using X (XKB) definitions; you can then set your
-keyboard layout more precisely with #{keyboard-layouts}#,
-#{keyboard-variant}#, #{keyboard-options}# and #{keyboard-model}# variables;
-live-boot will use also these parameters for X configuration. For example,
-to set up a French system with a French-Dvorak layout (called Bepo) on a
-TypeMatrix keyboard, both in console and X11, use:
-
-code{
-
- $ lb config --bootappend-live \
- "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"
-
-}code
-
-2~persistence Persistence
-
-A live cd paradigm is a pre-installed system which runs from read-only
-media, like a cdrom, where writes and modifications do not survive reboots
-of the host hardware which runs it.
-
-A Debian Live system is a generalization of this paradigm and thus supports
-other media in addition to CDs; but still, in its default behaviour, it
-should be considered read-only and all the run-time evolutions of the system
-are lost at shutdown.
-
-Persistence is a common name for different kinds of solutions for saving
-across reboots some, or all, of this run-time evolution of the system. To
-understand how it could work it could be handy to know that even if the
-system is booted and run from read-only media, modification to the files and
-directories are written on writable media, typically a ram disk (tmpfs) and
-ram disks' data do not survive reboots.
-
-The data stored on this ramdisk should be saved on a writable persistent
-medium like a Hard Disk, a USB key, a network share or even a session of a
-multisession (re)writable CD/DVD. All these media are supported in Debian
-Live in different ways, and all but the last one require a special boot
-parameter to be specified at boot time: #{persistent}#.
-
-3~ Full persistence
-
-By 'full persistence' it is meant that instead of using a tmpfs for storing
-modifications to the read-only media (with the copy-on-write, COW, system) a
-writable partition is used. In order to use this feature a partition with a
-clean writable supported filesystem on it labeled "live-rw" must be attached
-on the system at boot time and the system must be started with the boot
-parameter 'persistent'. This partition could be an ext2 partition on the
-hard disk or on a usb key created with, e.g.:
-
-code{
-
- # mkfs.ext2 -L live-rw /dev/sdb1
-
-}code
-
-See also {Using the space left on a USB stick}#using-usb-extra-space.
-
-If you already have a partition on your device, you could just change the
-label with one of the following:
-
-code{
-
- # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems
-
-}code
-
-But since live system users cannot always use a hard drive partition, and
-considering that most USB keys have poor write speeds, 'full' persistence
-could be also used with just image files, so you could create a file
-representing a partition and put this image file even on a NTFS partition of
-a foreign OS, with something like:
-
-code{
-
- $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
- $ /sbin/mkfs.ext2 -F live-rw
-
-}code
-
-Then copy the #{live-rw}# file to a writable partition and reboot with the
-boot parameter 'persistent'.
-
-3~ Home automounting
-
-If during the boot a partition (filesystem) image file or a partition
-labeled #{home-rw}# is discovered, this filesystem will be directly mounted
-as #{/home}#, thus permitting persistence of files that belong to e.g. the
-default user. It can be combined with full persistence.
-
-3~ Snapshots
-
-Snapshots are collections of files and directories which are not mounted
-while running but which are copied from a persistent device to the system
-(tmpfs) at boot and which are resynced at reboot/shutdown of the system. The
-content of a snapshot could reside on a partition or an image file (like the
-above mentioned types) labeled #{live-sn}#, but it defaults to a simple cpio
-archive named #{live-sn.cpio.gz}#. As above, at boot time, the block devices
-connected to the system are traversed to see if a partition or a file named
-like that could be found. A power interruption during run time could lead to
-data loss, hence a tool invoked #{live-snapshot --refresh}# could be called
-to sync important changes. This type of persistence, since it does not write
-continuously to the persistent media, is the most flash-based device
-friendly and the fastest of all the persistence systems.
-
-A /home version of snapshot exists too and its label is #{home-sn.*}#; it
-works the same as the main snapshot but it is only applied to /home.
-
-Snapshots cannot currently handle file deletion but full persistence and
-home automounting can.
-
-3~ Persistent SubText
-
-If a user would need multiple persistent storage of the same type for
-different locations or testing, such as #{live-rw-nonwork}# and
-#{live-rw-work}#, the boot parameter #{persistent-subtext}# used in
-conjunction with the boot parameter #{persistent}# will allow for multiple
-but unique persistent media. An example would be if a user wanted to use a
-persistent partition labeled #{live-sn-subText}# they would use the boot
-parameters of: #{persistent}# #{persistent-subtext=subText}#.
-
-3~ Partial remastering
-
-The run-time modification of the tmpfs could be collected using
-live-snapshot in a squashfs and added to the cd by remastering the iso in
-the case of cd-r or adding a session to multisession cd/dvd(rw); live-boot
-mounts all /live filesystem in order or with the module boot parameter.
diff --git a/manual/ro/user_examples.ssi b/manual/ro/user_examples.ssi
deleted file mode 100644
index 5bb918a..0000000
--- a/manual/ro/user_examples.ssi
+++ /dev/null
@@ -1,395 +0,0 @@
-:B~ Examples
-
-1~examples Examples
-
-This chapter covers example builds for specific use cases with Debian
-Live. If you are new to building your own Debian Live images, we recommend
-you first look at the three tutorials in sequence, as each one teaches new
-techniques that will help you use and understand the remaining examples.
-
-2~using-the-examples Using the examples
-
-To use these examples you need a system to build them on that meets the
-requirements listed in {Requirements}#requirements and has live-build
-installed as described in {Installing live-build}#installing-live-build.
-
-Note that, for the sake of brevity, in these examples we do not specify a
-local mirror to use for the build. You can speed up downloads considerably
-if you use a local mirror. You may specify the options when you use #{lb
-config}#, as described in {Distribution mirrors used at build
-time}#distribution-mirrors-build-time, or for more convenience, set the
-default for your build system in #{/etc/live/build.conf}#. Simply create
-this file and in it, set the corresponding #{LB_MIRROR_*}# variables to your
-preferred mirror. For example:
-
-code{
-
- LB_MIRROR_BOOTSTRAP="http://mirror/debian"
- LB_MIRROR_CHROOT="http://mirror/debian"
- LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
-
-}code
-
-2~tutorial-1 Tutorial 1: A standard image
-
-*{Use case:}* Create a simple first image, learning the basics of live-build.
-
-In this tutorial, we will build a default ISO hybrid Debian Live image
-containing only base packages (no Xorg) and some Debian Live support
-packages, as a first exercise in using live-build.
-
-You can't get much simpler than this:
-
-code{
-
- $ mkdir tutorial1 ; cd tutorial1 ; lb config
-
-}code
-
-Examine the contents of the #{config/}# directory if you wish. You will see
-stored here a skeletal configuration, ready to customize or, in this case,
-use immediately to build a default image.
-
-Now, as superuser, build the image, saving a log as you build with #{tee}#.
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Assuming all goes well, after a while, the current directory will contain
-#{binary-hybrid.iso}#. This ISO hybrid image can be booted directly in a
-virtual machine as described in {Testing an ISO image with
-Qemu}#testing-iso-with-qemu and {Testing an ISO image with
-virtualbox-ose}#testing-iso-with-virtualbox, or else imaged onto optical
-media or a USB flash device as described in {Burning an ISO image to a
-physical medium}#burning-iso-image and {Copying an ISO hybrid image to a USB
-stick}#copying-iso-hybrid-to-usb, respectively.
-
-2~tutorial-2 Tutorial 2: A web browser utility
-
-*{Use case:}* Create a web browser utility image, learning how to apply customizations.
-
-In this tutorial, we will create an image suitable for use as a web browser
-utility, serving as an introduction to customizing Debian Live images.
-
-code{
-
- $ mkdir tutorial2 ; cd tutorial2 ; lb config -p lxde --packages iceweasel
-
-}code
-
-Our choice of LXDE for this example reflects our desire to provide a minimal
-desktop environment, since the focus of the image is the single use we have
-in mind, the web browser. We could go even further and provide a default
-configuration for the web browser in
-#{config/chroot_local-includes/etc/iceweasel/profile/}#, or additional
-support packages for viewing various kinds of web content, but we leave this
-as an exercise for the reader.
-
-Build the image, again as superuser, keeping a log as in {Tutorial
-1}#tutorial-1:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-Again, verify the image is OK and test, as in {Tutorial 1}#tutorial-1.
-
-2~tutorial-3 Tutorial 3: A personalized image
-
-*{Use case:}* Create a project to build a personalized image, containing your favourite software to take with you on a USB stick wherever you go, and evolving in successive revisions as your needs and preferences change.
-
-Since we will be changing our personalized image over a number of revisions,
-and we want to track those changes, trying things experimentally and
-possibly reverting them if things don't work out, we will keep our
-configuration in the popular #{git}# version control system. We will also
-use the best practice of autoconfiguration via #{auto}# scripts as described
-in {Managing a configuration}#managing-a-configuration.
-
-3~ First revision
-
-code{
-
- $ mkdir -p tutorial3/auto
- $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
- $ cd tutorial3
-
-}code
-
-Edit #{auto/config}# to read as follows:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat" \
- "${@}"
-
-}code
-
-First, #{--architecture 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}# 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:
-
-code{
-
- # lb build
-
-}code
-
-Note that unlike in the first two tutorials, we no longer have to type
-#{2>&1 | tee binary.log}# as that is now included in #{auto/build}#.
-
-Once you've tested the image (as in {Tutorial 1}#tutorial-1) and are
-satisfied it works, it's time to initialize our #{git}# repository, adding
-only the auto scripts we just created, and then make the first commit:
-
-code{
-
- $ git init
- $ git add auto
- $ git commit -a -m "Initial import."
-
-}code
-
-3~ Second revision
-
-In this revision, we're going to clean up from the first build, add the
-#{vlc}# package to our configuration, rebuild, test and commit.
-
-The #{lb clean}# command will clean up all generated files from the previous
-build except for the cache, which saves having to re-download packages. This
-ensures that the subsequent #{lb build}# will re-run all stages to
-regenerate the files from our new configuration.
-
-code{
-
- # lb clean
-
-}code
-
-Now edit #{auto/config}# to add the #{vlc}# package:
-
-code{
-
- #!/bin/sh
-
- lb config noauto \
- --architecture i386 \
- --linux-flavours 686 \
- --packages-lists lxde \
- --packages "iceweasel xchat vlc" \
- "${@}"
-
-}code
-
-Build again:
-
-code{
-
-# lb build
-
-}code
-
-Test, and when you're satisfied, commit the next revision:
-
-code{
-
- $ git commit -a -m "Adding vlc media player."
-
-}code
-
-Of course, more complicated changes to the configuration are possible,
-perhaps adding files in subdirectories of #{config/}#. When you commit new
-revisions, just take care not to hand edit or commit the top-level files in
-#{config}# containing #{LB_*}# variables, as these are build products, too,
-and are always cleaned up by #{lb clean}# and re-created with #{lb config}#
-via their respective #{auto}# scripts.
-
-We've come to the end of our tutorial series. While many more kinds of
-customization are possible, even just using the few features explored in
-these simple examples, an almost infinite variety of different images can be
-created. The remaining examples in this section cover several other use
-cases drawn from the collected experiences of users of Debian Live.
-
-2~ A VNC Kiosk Client
-
-*{Use case:}* Create an image with live-build to boot directly to a VNC server.
-
-Make a build directory and create a skeletal configuration in it built
-around the standard-x11 list, including #{gdm3}#, #{metacity}# and
-#{xtightvncviewer}#, disabling recommends to make a minimal system:
-
-code{
-
- $ mkdir vnc_kiosk_client
- $ cd vnc_kiosk_client
- $ lb config -a i386 -k 686 -p standard-x11 \
- --packages "gdm3 metacity xvnc4viewer" \
- --apt-recommends false
-
-}code
-
-Create the directory #{/etc/skel}# and put a custom #{.xsession}# in it for
-the default user that will launch metacity and start xvncviewer, connecting
-to port #{5901}# on a server at #{192.168.1.2}#:
-
-code{
-
- $ mkdir -p config/chroot_local-includes/etc/skel
- $ cat >config/chroot_local-includes/etc/skel/.xsession <<END
- #!/bin/sh
-
- /usr/bin/metacity &
- /usr/bin/xvncviewer 192.168.1.2:1
-
- exit
- END
-
-}code
-
-Build the image:
-
-code{
-
- # lb build
-
-}code
-
-Enjoy.
-
-2~ A base image for a 128M USB key
-
-*{Use case:}* Create a standard image with some components removed in order to fit on a 128M USB key with space left over to use as you see fit.
-
-When optimizing an image to fit a certain media size, you need to understand
-the tradeoffs you are making between size and functionality. In this
-example, we trim only so much as to make room for additional material within
-a 128M media size, but without doing anything to destroy integrity of the
-packages contained within, such as the purging of locale data via the
-#{localepurge}# package, or other such "intrusive" optimizations. Of
-particular note, you should not use #{--bootstrap-flavour minimal}# unless
-you really know what you're doing, as omitting priority #{important}#
-packages will most likely produce a broken live system.
-
-code{
-
- $ lb config -k 486 -p minimal --binary-indices false \
- --memtest none --apt-recommends false --includes none
-
-}code
-
-Now, build the image in the usual way:
-
-code{
-
- # lb build 2>&1 | tee binary.log
-
-}code
-
-On the author's system at time of writing, the above configuration produced
-a 78Mbyte image. This compares favourably with the 166Mbyte image produced
-by the default configuration in {Tutorial 1}#tutorial-1.
-
-The biggest space-saver here, compared to building a standard image on an
-#{i386}# architecture system, is to select only the #{486}# kernel flavour
-instead of the default #{-k "486 686"}#. Leaving off APT's indices with
-#{--binary-indices false}# also saves a fair amount of space, the tradeoff
-being that you need to #{apt-get update}# before using apt in the live
-system. Choosing the #{minimal}# package list leaves out the large
-#{locales}# package and associated utilities. Dropping recommended packages
-with #{--apt-recommends false}# saves some additional space, at the expense
-of omitting some packages you might otherwise expect to be there, such as
-#{firmware-linux-free}# which may be needed to support certain hardware. The
-remaining options shave off additional small amounts of space. It's up to
-you to decide if the functionality that is sacrificed with each optimization
-is worth the loss in functionality.
-
-2~ A localized KDE desktop and installer
-
-*{Use case:}* Create a KDE desktop image, localized for Brazilian Portuguese and including an installer.
-
-We want to make an iso-hybrid image for i386 architecture using our
-preferred desktop, in this case KDE, containing all of the same packages
-that would be installed by the standard Debian installer for KDE.
-
-Our initial problem is the discovery of the names of the appropriate
-tasks. Currently, live-build cannot help with this. While we might get lucky
-and find this by trial-and-error, there is a tool, #{grep-dctrl}#, which can
-be used to dig it out of the task descriptions in tasksel-data, so to
-prepare, make sure you have both of those things:
-
-code{
-
- # apt-get install dctrl-tools tasksel-data
-
-}code
-
-Now we can search for the appropriate tasks, first with:
-
-code{
-
- $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese
- Description: Brazilian Portuguese environment
- This task installs programs, data files, and
- documentation that make it easier for Brazilian Portuguese speakers
- to use Debian.
-
-}code
-
-By this command, we discover the task is called, plainly enough,
-brazilian-portuguese. Now to find the related tasks:
-
-code{
-
- $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/debian-tasks.desc -sTask,Description
- Task: brazilian-portuguese-desktop
- Description: Brazilian Portuguese desktop
- This task localises the desktop in Brasilian Portuguese.
-
- Task: brazilian-portuguese-kde-desktop
- Description: Brazilian Portuguese KDE desktop
- This task localises the KDE desktop in Brazilian Portuguese.
-
-}code
-
-We will use the experimental #{--language}# option, as live-build happens to
-include #{syslinux}# templates for pt_BR (see {Desktop and language
-tasks}#desktop-and-language-tasks for details). And at boot time we will
-generate the pt_BR.UTF-8 locale and select the pt-latin1 keyboard
-layout. Now let's put the pieces together:
-
-code{
-
- $ mkdir live-pt_BR-kde
- $ cd live-pt_BR-kde
- $ lb config \
- -a i386 \
- -k 486 \
- -p kde-desktop \
- --language pt_BR \
- --tasks "brazilian-portuguese brazilian-portuguese-desktop brazilian-portuguese-kde-desktop" \
- --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
- --debian-installer live \
- --packages debian-installer-launcher
-
-}code
-
-Note that we have included the #{debian-installer-launcher}# package to
-launch the installer from the live desktop, and have also specified the 486
-flavour kernel, as it is currently necessary to make the installer and live
-system kernels match for the launcher to work properly.
diff --git a/manual/ro/user_installation.ssi b/manual/ro/user_installation.ssi
deleted file mode 100644
index badc83f..0000000
--- a/manual/ro/user_installation.ssi
+++ /dev/null
@@ -1,174 +0,0 @@
-:B~ Installation
-
-1~installation Installation
-
-2~requirements Requirements
-
-Building Debian Live images has very few system requirements:
-
-_* Super user (root) access
-
-_* An up-to-date version of live-build
-
-_* A POSIX-compliant shell, such as /{bash}/ or /{dash}/.
-
-_* /{debootstrap}/ or /{cdebootstrap}/
-
-_* Linux 2.6.x
-
-Note that using Debian or a Debian-derived distribution is not required -
-live-build will run on almost any distribution with the above requirements.
-
-2~installing-live-build Installing live-build
-
-You can install live-build in a number of different ways:
-
-_* From the Debian repository
-
-_* From source
-
-_* From snapshots
-
-If you are using Debian, the recommended way is to install live-build via
-the Debian repository.
-
-3~ From the Debian repository
-
-Simply install live-build like any other package:
-
-code{
-
- # apt-get install live-build
-
-}code
-
-or
-
-code{
-
- # aptitude install live-build
-
-}code
-
-3~ From source
-
-live-build is developed using the Git version control system. On Debian
-based systems, this is provided by the /{git}/ package. To check out the
-latest code, execute:
-
-code{
-
- $ git clone git://live.debian.net/git/live-build.git
-
-}code
-
-You can build and install your own Debian package by executing:
-
-code{
-
- $ cd live-build
- $ dpkg-buildpackage -rfakeroot -b -uc -us
- $ cd ..
-
-}code
-
-Now install whichever of the freshly built #{.deb}# files you were
-interested in, e.g.
-
-code{
-
- # dpkg -i live-build_2.0.8-1_all.deb
-
-}code
-
-You can also install live-build directly to your system by executing:
-
-code{
-
- # make install
-
-}code
-
-and uninstall it with:
-
-code{
-
- # make uninstall
-
-}code
-
-3~ From 'snapshots'
-
-If you do not wish to build or install live-build from source, you can use
-snapshots. These are built automatically from the latest version in Git and
-are available on http://live.debian.net/debian/.
-
-2~ live-boot and live-config
-
-*{Note:}* You do not need to install live-boot or live-config on your system to create customized Debian Live systems. However, doing so will do no harm and is useful for reference purposes. If you only want the documentation, you may now install the live-boot-doc and live-config-doc packages separately.
-
-3~ From the Debian repository
-
-Both live-boot and live-config are available from the Debian repository as
-per {Installing live-build}#installing-live-build.
-
-3~ From source
-
-To use the latest source from git, you can follow the process below. Please
-ensure you are familiar with the terms mentioned in {Terms}#terms.
-
-_* Checkout the live-boot and live-config source
-
-code{
-
- $ git clone git://live.debian.net/git/live-boot.git
- $ git clone git://live.debian.net/git/live-config.git
-
-}code
-
-Consult the live-boot and live-config man pages for details on customizing
-if that is your reason for building these packages from source.
-
-_* Build live-boot and live-config .deb files
-
-You must build either on your target distribution or in a chroot containing
-your target platform: this means if your target is Squeeze then you should
-build against Squeeze.
-
-Use a personal builder such as /{pbuilder}/ or /{sbuild}/ if you need to
-build #{live-boot}# for a target distribution that differs from your build
-system. For example, for Squeeze live images, build #{live-boot}# in a
-Squeeze chroot. If your target distribution happens to match your build
-system distribution, you may build directly on the build system using
-#{dpkg-buildpackage}# (provided by the /{dpkg-dev}/ package):
-
-code{
-
- $ cd live-boot
- $ dpkg-buildpackage -b -uc -us
- $ cd ../live-config
- $ dpkg-buildpackage -b -uc -us
-
-}code
-
-_* Use all generated .deb files
-
-As live-boot and live-config are installed by live-build system, installing
-the packages in the host system is not sufficient: you should treat the
-generated .deb files like any other custom packages. Please see {Customizing
-package installation}#customizing-package-installation for more
-information. You should pay particular attention to {Additional
-repositories}#additional-repositories.
-
-3~ From 'snapshots'
-
-You can let live-build automatically use the latest snapshots of live-boot
-and live-config by configuring a third-party repository in your live-build
-configuration directory. Assuming you have already created a configuration
-tree in the current directory with #{lb config}#:
-
-code{
-
- $ lb config --archives live.debian.net
-
-}code
diff --git a/manual/ro/user_managing_a_configuration.ssi b/manual/ro/user_managing_a_configuration.ssi
deleted file mode 100644
index 999c508..0000000
--- a/manual/ro/user_managing_a_configuration.ssi
+++ /dev/null
@@ -1,94 +0,0 @@
-:B~ Managing a configuration
-
-1~managing-a-configuration Managing a configuration
-
-This chapter explains how to manage a live configuration from initial
-creation, through successive revisions and successive releases of both the
-live-build software and the live image itself.
-
-2~ Use auto to manage configuration changes
-
-Live configurations rarely are perfect on the first try. You'll likely need
-to make a series of revisions until you are satisfied. However,
-inconsistencies can creep into your configuration from one revision to the
-next if you aren't careful. The main problem is, once a variable is given a
-default value, that value will not be recomputed from other variables that
-may change in later revisions.
-
-For example, when the distribution is first set, many 'dependent' variables
-are given default values that suit that distribution. However, if you later
-decide to change the distribution, those dependent variables continue to
-retain old values that are no longer appropriate.
-
-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 #{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).
-
-2~ Example auto scripts
-
-Use auto script examples such as the following as the starting point for
-your new live-build configuration. Take note that when you call the #{lb}#
-command that the auto script wraps, you must specify #{noauto}# as its
-parameter to ensure that the auto script isn't called again,
-recursively. Also, don't forget to ensure the scripts are executable
-(e.g. #{chmod 755 auto/*}#).
-
-#{auto/config}#
-
-code{
-
- #!/bin/sh
- lb config noauto \
- --packages-lists "standard" \
- "${@}"
-
-}code
-
-#{auto/clean}#
-
-code{
-
- #!/bin/sh
- lb clean noauto "${@}"
- rm -f config/binary config/bootstrap \
- config/chroot config/common config/source
- rm -f binary.log
-
-}code
-
-#{auto/build}#
-
-code{
-
- #!/bin/sh
- lb build noauto "${@}" 2>&1 | tee binary.log
-
-}code
-
-We now ship example auto scripts with live-build based on the examples
-above. You may copy those as your starting point.
-
-code{
-
- $ cp /usr/share/live/build/examples/auto/* auto/
-
-}code
-
-Edit #{auto/config}#, changing or adding any options as you see fit. In the
-example above, #{--packages-lists standard}# is set to the default
-value. Change this to an appropriate value for your image (or delete it if
-you want to use the default) and add any additional options in continuation
-lines that follow.
diff --git a/manual/ro/user_overview.ssi b/manual/ro/user_overview.ssi
deleted file mode 100644
index ddb3b58..0000000
--- a/manual/ro/user_overview.ssi
+++ /dev/null
@@ -1,158 +0,0 @@
-:B~ Overview of tools
-
-1~overview-of-tools Overview of tools
-
-This chapter contains an overview of the three main tools used in building
-Debian Live systems: live-build, live-boot and live-config.
-
-2~live-build live-build
-
-live-build is a collection of scripts to build Debian Live systems. These
-scripts are also referred to as "commands".
-
-The idea behind live-build is to be a framework that uses a configuration
-directory to completely automate and customize all aspects of building a
-Live image.
-
-Many concepts are similar to those in the debhelper Debian package tools
-written by Joey Hess:
-
-_* The scripts have a central location for configuring their operation. In
-debhelper, this is the #{debian/}# subdirectory of a package tree. For
-example, dh_install will look, amongst others, for a file called
-#{debian/install}# to determine which files should exist in a particular
-binary package. In much the same way, live-build stores its configuration
-entirely under a #{config/}# subdirectory.
-
-_* 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.
-
-The remainder of this section discusses the three most important commands:
-
-_* *{lb config}*: Responsible for initializing a Live system configuration
-directory. See {The lb config command}#lb-config for more information.
-
-_* *{lb build}*: Responsible for starting a Live system build. See {The lb
-build command}#lb-build for more information.
-
-_* *{lb clean}*: Responsible for removing parts of a Live system build. See
-{The lb clean command}#lb-clean for more information.
-
-3~lb-config The #{lb config}# command
-
-As discussed in {live-build}#live-build, the scripts that make up live-build
-read their configuration with the #{source}# command from a single directory
-named #{config/}#. As constructing this directory by hand would be
-time-consuming and error-prone, the #{lb config}# command can be used to
-create skeleton configuration folders.
-
-Issuing #{lb config}# without any arguments creates a #{config/}#
-subdirectory which it populates with some default settings:
-
-code{
-
- $ lb config
- P: Creating config tree
-
- $ ls -l
- total 8
- drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
- drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
-
- $ ls -l config/
- total 104
- -rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
- -rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
- -rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
- -rw-r--r-- 1 user user 2954 Sep 7 13:02 common
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
- -rw-r--r-- 1 user user 205 Sep 7 13:02 source
- drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
-
-}code
-
-Using #{lb config}# without any arguments would be suitable for users who
-need a very basic image, or who intend to later provide a more complete
-configuration via auto/config (see {Managing a
-configuration}#managing-a-configuration for details).
-
-Normally, you will want to specify some options. For example, to include the
-'gnome' package list in your configuration:
-
-code{
-
- $ lb config -p gnome
-
-}code
-
-It is possible to specify many options, such as:
-
-code{
-
- $ lb config --binary-images net --hostname live-machine --username live-user ...
-
-}code
-
-A full list of options is available in the #{lb_config}# man page.
-
-3~lb-build The #{lb build}# command
-
-The #{lb build}# command reads in your configuration from the config/
-directory. It then runs the lower level commands needed to build your Live
-system.
-
-3~lb-clean The #{lb clean}# command
-
-It is the job of the #{lb clean}# command to remove various parts of a build
-so subsequent builds can start from a clean state. By default, #{chroot}#,
-#{binary}# and #{source}# stages are cleaned, but the cache is left
-intact. Also, individual stages can be cleaned. For example, if you have
-made changes that only affect the binary stage, use #{lb clean --binary}#
-prior to building a new binary. See the #{lb_clean}# man page for a full
-list of options.
-
-2~live-boot The live-boot package
-
-live-boot is a collection of scripts providing hooks for the
-initramfs-tools, used to generate an initramfs capable of booting live
-systems, such as those created by live-build. This includes the Debian Live
-ISOs, netboot tarballs, and USB stick images.
-
-At boot time it will look for read-only media containing a "/live" directory
-where a root filesystem (often a compressed filesystem image like squashfs)
-is stored. If found, it will create a writable environment, using aufs, for
-Debian like systems to boot from.
-
-More information on initial ramfs in Debian can be found in the Debian Linux
-Kernel Handbook at http://kernel-handbook.alioth.debian.org/ in the chapter
-on initramfs.
-
-2~live-config The live-config package
-
-live-config consists of the scripts that run at boot time after live-boot to
-configure the live system automatically. It handles such tasks as setting
-the hostname, locales and timezone, creating the live user, inhibiting cron
-jobs and performing autologin of the live user.
--
live-manual
More information about the debian-live-changes
mailing list