Changeset c093e6b for chapter04

Timestamp:

10/01/2022 10:30:12 PM (19 months ago)

Author:

Thomas Trepl (Moody) <thomas@…>

Branches:

multilib

Children:

f3b2f16

Parents:

f29824e (diff), 4349661 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Automatic merge of trunk into multilib

Location:

chapter04

Files:

• aboutsbus.xml (modified) (4 diffs)
• abouttestsuites.xml (modified) (2 diffs)
• addinguser.xml (modified) (6 diffs)
• creatingminlayout.xml (modified) (2 diffs)
• introduction.xml (modified) (1 diff)
• settingenviron.xml (modified) (6 diffs)

chapter04/aboutsbus.xml

@@ -14 +14 @@
   it takes to compile and install each package. Because Linux From
   Scratch can be built on many different systems, it is impossible to
-  provide accurate time estimates. The biggest package (Glibc) will
+  provide absolute time estimates. The biggest package (Glibc) will
   take approximately 20 minutes on the fastest systems, but could take
   up to three days on slower systems! Instead of providing actual times,
@@ -21 +21 @@
 
   <para>The SBU measure works as follows. The first package to be compiled
-  from this book is binutils in <xref linkend="chapter-cross-tools"/>. The
-  time it takes to compile this package is what will be referred to as the
-  Standard Build Unit or SBU. All other compile times will be expressed relative
-  to this time.</para>
+  is binutils in <xref linkend="chapter-cross-tools"/>. The
+  time it takes to compile this package is what we will refer to as the
+  Standard Build Unit or SBU. All other compile times will be expressed in
+  terms of this unit of time.</para>
 
   <para>For example, consider a package whose compilation time is 4.5
-  SBUs. This means that if a system took 10 minutes to compile and
+  SBUs. This means that if your system took 10 minutes to compile and
   install the first pass of binutils, it will take
-  <emphasis>approximately</emphasis> 45 minutes to build this example package.
-  Fortunately, most build times are shorter than the one for binutils.</para>
+  <emphasis>approximately</emphasis> 45 minutes to build the example package.
+  Fortunately, most build times are shorter than one SBU.</para>
 
-  <para>In general, SBUs are not entirely accurate because they depend on many
+  <para>SBUs are not entirely accurate because they depend on many
   factors, including the host system's version of GCC.  They are provided here
   to give an estimate of how long it might take to install a package, but the
@@ -46 +46 @@
     <screen role="nodump"><userinput>export MAKEFLAGS='-j4'</userinput></screen>
 
-    <para>or just building with:</para>
+    <para>or by building with:</para>
 
     <screen role="nodump"><userinput>make -j4</userinput></screen>
@@ -53 +53 @@
     book will vary even more than they normally would.  In some cases, the make
     step will simply fail.  Analyzing the output of the build process will also
-    be more difficult because the lines of different processes will be
-    interleaved.  If you run into a problem with a build step, revert back to a
+    be more difficult because the lines from different processes will be
+    interleaved.  If you run into a problem with a build step, revert to a
     single processor build to properly analyze the error messages.</para>
   </note>

chapter04/abouttestsuites.xml

@@ -28 +28 @@
     <para>Running the test suites in <xref linkend="chapter-cross-tools"/>
     and <xref linkend="chapter-temporary-tools"/>
-    is impossible, since the programs are compiled with a cross-compiler,
-    so are not supposed to be able to run on the build host.</para>
+    is pointless; since the test programs are compiled with a cross-compiler,
+    they probably can't run on the build host.</para>
   </note>
 
   <para>A common issue with running the test suites for binutils and GCC
-  is running out of pseudo terminals (PTYs). This can result in a high
+  is running out of pseudo terminals (PTYs). This can result in a large
   number of failing tests. This may happen for several reasons, but the
   most likely cause is that the host system does not have the
@@ -40 +40 @@
   <ulink url="&lfs-root;lfs/faq.html#no-ptys"/>.</para>
 
-  <para>Sometimes package test suites will fail, but for reasons which the
+  <para>Sometimes package test suites will fail for reasons which the
   developers are aware of and have deemed non-critical. Consult the logs located
   at <ulink url="&test-results;"/> to verify whether or not these failures are
-  expected. This site is valid for all tests throughout this book.</para>
+  expected. This site is valid for all test suites throughout this book.</para>
 
 </sect1>

chapter04/addinguser.xml

@@ -15 +15 @@
   the packages in the next two chapters are built as an unprivileged user.
   You could use your own user name, but to make it easier to set up a clean
-  working environment, create a new user called <systemitem
+  working environment, we will create a new user called <systemitem
   class="username">lfs</systemitem> as a member of a new group (also named
-  <systemitem class="groupname">lfs</systemitem>) and use this user during
+  <systemitem class="groupname">lfs</systemitem>) and run commands as &lfs-user; during
   the installation process. As <systemitem class="username">root</systemitem>,
   issue the following commands to add the new user:</para>
@@ -25 +25 @@
 
   <variablelist>
-    <title>The meaning of the command line options:</title>
+    <title>This is what the command line options mean:</title>
 
     <varlistentry>
@@ -55 +55 @@
       <listitem>
         <para>This parameter prevents possible copying of files from a skeleton
-        directory (default is <filename class="directory">/etc/skel</filename>)
+        directory (the default is <filename class="directory">/etc/skel</filename>)
         by changing the input location to the special null device.</para>
       </listitem>
@@ -69 +69 @@
   </variablelist>
 
-  <para>To log in as <systemitem class="username">lfs</systemitem> (as opposed
-  to switching to user <systemitem class="username">lfs</systemitem> when logged
-  in as <systemitem class="username">root</systemitem>, which does not require
-  the <systemitem class="username">lfs</systemitem> user to have a password),
-  give <systemitem class="username">lfs</systemitem> a password:</para>
+  <para>If you want to log in as &lfs-user; or switch to &lfs-user; from a
+  non-&root; user (as opposed to switching to user &lfs-user;
+  when logged in as &root;, which does not require the &lfs-user; user to
+  have a password), you need to set a password of &lfs-user;.  Issue the
+  following command as the &root; user to set the password:</para>
 
 <screen role="nodump"><userinput>passwd lfs</userinput></screen>
 
   <para>Grant <systemitem class="username">lfs</systemitem> full access to
-  all directories under <filename class="directory">$LFS</filename> by making
-  <systemitem class="username">lfs</systemitem> the directory owner:</para>
+  all the directories under <filename class="directory">$LFS</filename> by making
+  <systemitem class="username">lfs</systemitem> the owner:</para>
 
 <screen><userinput>chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
@@ -89 +89 @@
 <screen arch="ml_all" ><userinput>chown -v lfs $LFS/{lib32,libx32}</userinput></screen>
 
-  <note><para>In some host systems, the following command does not complete
-  properly and suspends the login to the &lfs-user; user to the background.
+<note><para>In some host systems, the following <command>su</command> command does not complete
+  properly and suspends the login for the &lfs-user; user to the background.
   If the prompt "lfs:~$" does not appear immediately, entering the
   <command>fg</command> command will fix the issue.</para></note>
 
-  <para>Next, login as user <systemitem class="username">lfs</systemitem>.
-  This can be done via a virtual console, through a display manager, or with
-  the following substitute/switch user command:</para>
+  <para>Next, start a shell running as user &lfs-user;. This can be done by
+  logging in as &lfs-user; on a virtual console, or with the following
+  substitute/switch user command:</para>
 
 <screen role="nodump"><userinput>su - lfs</userinput></screen>
@@ -102 +102 @@
   <para>The <quote><parameter>-</parameter></quote> instructs
   <command>su</command> to start a login shell as opposed to a non-login shell.
-  The difference between these two types of shells can be found in detail in
+  The difference between these two types of shells is described in detail in
   <filename>bash(1)</filename> and <command>info bash</command>.</para>
 

chapter04/creatingminlayout.xml

@@ -11 +11 @@
   <title>Creating a limited directory layout in LFS filesystem</title>
 
-  <para>The first task performed in the LFS partition is to create a limited
-  directory hierarchy so that programs compiled in <xref
+  <para>In this section, we begin populating the LFS filesystem with the
+  pieces that will constitute the final Linux system. The first step is to
+  create a limited directory hierarchy, so that the programs compiled in <xref
   linkend="chapter-temporary-tools"/> (as well as glibc and libstdc++ in <xref
-  linkend="chapter-cross-tools"/>) may be installed in their final
-  location. This is needed so that those temporary programs be overwritten
-  when rebuilding them in <xref linkend="chapter-building-system"/>.</para>
+  linkend="chapter-cross-tools"/>) can be installed in their final
+  location. We do this so those temporary programs will be overwritten when
+  the final versions are built in <xref linkend="chapter-building-system"/>.</para>
 
-  <para>Create the required directory layout by running the following as
+  <para>Create the required directory layout by issuing the following commands as
   <systemitem class="username">root</systemitem>:</para>
 
@@ -39 +40 @@
 
   <para>Programs in <xref linkend="chapter-temporary-tools"/> will be compiled
-  with a cross-compiler (more details in section <xref
-  linkend="ch-tools-toolchaintechnotes"/>). In order to separate this
-  cross-compiler from the other programs, it will be installed in a special
-  directory. Create this directory with:</para>
+  with a cross-compiler (more details can be found in section <xref
+  linkend="ch-tools-toolchaintechnotes"/>). This cross-compiler will be installed
+  in a special directory, to separate it from the other programs. Still acting as
+  &root;, create that directory with this command:</para>
 
 <screen><userinput>mkdir -pv $LFS/tools</userinput></screen>

chapter04/introduction.xml

@@ -13 +13 @@
   <para>In this chapter, we will perform a few additional tasks to prepare
   for building the temporary system. We will create a set of directories in
-  <filename class="directory">$LFS</filename> for the installation of the
-  temporary tools, add an unprivileged user to reduce risk,
+  <filename class="directory">$LFS</filename> (in which we will install the
+  temporary tools), add an unprivileged user,
   and create an appropriate build environment for that user. We will also
-  explain the unit of time we use to measure how long LFS packages take to
-  build, or <quote>SBUs</quote>, and give some information about package
+  explain the units of time (<quote>SBUs</quote>) we use to measure how
+  long it takes to build LFS packages, and provide some information about package
   test suites.</para>
 

chapter04/settingenviron.xml

@@ -20 +20 @@
 EOF</userinput></screen>
 
-  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
-  the initial shell is usually a <emphasis>login</emphasis> shell which reads
+  <para>When logged on as user <systemitem class="username">lfs</systemitem>
+  or switched to the &lfs-user; user using a <command>su</command> command
+  with <quote><parameter>-</parameter></quote> option,
+  the initial shell is a <emphasis>login</emphasis> shell which reads
   the <filename>/etc/profile</filename> of the host (probably containing some
   settings and environment variables) and then <filename>.bash_profile</filename>.
@@ -33 +35 @@
 
   <para>The new instance of the shell is a <emphasis>non-login</emphasis>
-  shell, which does not read, and execute, the contents of <filename>/etc/profile</filename> or
+  shell, which does not read, and execute, the contents of the <filename>/etc/profile</filename> or
   <filename>.bash_profile</filename> files, but rather reads, and executes, the
   <filename>.bashrc</filename> file instead. Create the
@@ -74 +76 @@
   <command>bash</command>'s hash function. Hashing is ordinarily a useful
   feature&mdash;<command>bash</command> uses a hash table to remember the
-  full path of executable files to avoid searching the <envar>PATH</envar>
+  full path to executable files to avoid searching the <envar>PATH</envar>
   time and again to find the same executable. However, the new tools should
-  be used as soon as they are installed. By switching off the hash function,
-  the shell will always search the <envar>PATH</envar> when a program is to
+  be used as soon as they are installed. Switching off the hash function forces
+  the shell to search the <envar>PATH</envar> whenever a program is to
   be run. As such, the shell will find the newly compiled tools in
   <filename class="directory">$LFS/tools/bin</filename> as soon as they are
@@ -130 +132 @@
       <term><parameter>PATH=/usr/bin</parameter></term>
       <listitem>
-  <para>Many modern linux distributions have merged <filename
+  <para>Many modern Linux distributions have merged <filename
   class="directory">/bin</filename> and <filename
   class="directory">/usr/bin</filename>. When this is the case, the standard
-  <envar>PATH</envar> variable needs just to be set to <filename
+  <envar>PATH</envar> variable should be set to <filename
   class="directory">/usr/bin/</filename> for the <xref
   linkend="chapter-temporary-tools"/> environment. When this is not the
@@ -156 +158 @@
   of <xref linkend="chapter-cross-tools"/> is picked up by the shell
   immediately after its installation. This, combined with turning off hashing,
-  limits the risk that the compiler from the host be used instead of the
+  limits the risk that the compiler from the host is used instead of the
   cross-compiler.</para>
       </listitem>
@@ -210 +212 @@
 
   <para>Finally, to have the environment fully prepared for building the
-  temporary tools, source the just-created user profile:</para>
+  temporary tools, force the <command>bash</command> shell to read
+  the new user profile:</para>
 
 <screen><userinput>source ~/.bash_profile</userinput></screen>