Tuesday 27 July 2010

LAP - Actual Build - Part 7, A-Z

We are now moving on to build the remaining packages in roughly alphabetical order.  This suggests to me that either all the dependancy issues have been resolved, or it is a MASSIVE coincidence that the order for the build of all these packages just happens to be alphabetical.

First up is  new package, autoconf.  Like the next package, automake, these are both needed for automatic routines in (re)building software from source code.
tar -xjvf /sources/autoconf-2.65.tar.bz2
cd autoconf-2.65
./configure --prefix=/usr
make $CORES_TO_USE
make $CORES_TO_USE check

## ------------- ## 
## Test results. ## 
## ------------- ## 

414 tests behaved as expected. 
25 tests were skipped.

This one took over 10 minutes on my Quad Core, but it was reduced to under 9 minutes with the ramdisk approach.

make install
cd ..
rm -rvf autoconf-2.65

tar -xjvf /sources/automake-1.11.1.tar.bz2
cd automake-1.11.1
./configure --prefix=/usr --docdir=/usr/share/doc/automake-1.11.1
make $CORES_TO_USE
make $CORES_TO_USE check

===================================== 
1 of 672 tests failed 
(63 tests were not run) 
See tests/test-suite.log 
Please report to bug-automake@gnu.org 
===================================== 

Oh dear.  This is the first unexpected failure that I have come across.  I spent a bit of time looking into this.  The whole report in the test suit about the failure looks like this:

FAIL: acloca22.test (exit: 1)
=============================

/sources/automake-1.11.1/tests:/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
=== Running test ./acloca22.test
++ pwd
/sources/automake-1.11.1/tests/acloca22.dir
+ set -e
+ cat
+ cat
+ cat
+ cat
+ aclocal-1.11 -Werror -I .
+ automake-1.11 --foreign -Werror -Wall
+ autoconf
+ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating Makefile
+ make
make: Nothing to be done for `all'.
+ grep GREPFOO Makefile
GREPFOO = 
+ grep GREPBAR Makefile
+ sed s/FOO/BAR/
+ mv -f t configure.in
+ rm -f foo.m4
+ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /sources/automake-1.11.1/tests/acloca22.dir/missing --run aclocal-1.11 -I .
 cd . && /bin/sh /sources/automake-1.11.1/tests/acloca22.dir/missing --run automake-1.11 --foreign
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /sources/automake-1.11.1/tests/acloca22.dir/missing --run autoconf
make: Nothing to be done for `all'.
+ grep GREPFOO Makefile
GREPFOO = 
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ exit_status=1
+ set +e
+ cd /sources/automake-1.11.1/tests
+ case $exit_status,$keep_testdirs in
+ test 0 '!=' 0
+ echo 'acloca22: exit 1'
acloca22: exit 1
+ exit 1

I have concluded precisely jack shit from that.  I then googled for 'FAIL: acloca22.test'.  I found some other people on the LFS Mailing list referring to this.  I also, critically found the official build logs for LFS 6.6 here [http://www.linuxfromscratch.org/lfs/build-logs/6.6/core2duo/test-logs/095-automake] which includes another acloca??.test failure.  I have resolved to carry on regardless, and I will see what happens.  It would be spiffing if the book could flag up that this is a problem, like with GCC and its muddy flaps.

make install
cd ..
rm -rvf automake-1.11.1

Next we need bzip2 again:

tar -xzvf /sources/bzip2-1.0.5.tar.gz
cd bzip2-1.0.5

We want to install the documentation for this (no really we do) and this is best achieved by applying a patch with a really simple output:
patch -Np1 -i /sources/bzip2-1.0.5-install_docs-1.patch

patching file Makefile 

sed -i 's@\(ln -s -f \)$(PREFIX)/bin/@\1@' Makefile

A, sed my old friend.  Still as completely fucking impenetrable as ever eh?  The books tells us that “The […] command ensures installation of symbolic links are relative”.  Riiiight.  Again, I know what every word in that sentence means individually but put them together and snorkel my plunge aardvark if I coin my plain!

make -f Makefile-libbz2_so

This is on about dynamic libraries again.  Apparently if the normal Makefile (some sort of script apparently) is used then you don't get the lovely dynamic libraries that are all the rage these days.
make clean

Bit odd that we are doing a make clean at this stage.  Must make sense to someone.

make $CORES_TO_USE
make PREFIX=/usr install

Finally we need to rearrange some of the installed files again:
cp -v bzip2-shared /bin/bzip2 
cp -av libbz2.so* /lib 
ln -sv ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so 
rm -v /usr/bin/{bunzip2,bzcat,bzip2} 
ln -sv bzip2 /bin/bunzip2 
ln -sv bzip2 /bin/bzcat 
cd ..
rm -rvf bzip2-1.0.5

Diffutils was also in the Toolchain.

tar -xzvf /sources/diffutils-2.8.1.tar.gz
cd diffutils-2.8.1

We need another patch to correct a localisation issue.  This has something to do with treating white spaces according to their current locale; which frankly sounds a bit racist to me.
patch -Np1 -i /sources/diffutils-2.8.1-i18n-1.patch

patching file src/diff.c 
Hunk #1 succeeded at 273 (offset -2 lines). 
patching file src/diff.h 
Hunk #1 succeeded at 25 with fuzz 2 (offset 2 lines). 
Hunk #2 succeeded at 362 (offset -1 lines). 
patching file src/io.c 
Hunk #1 succeeded at 25 (offset -1 lines). 
Hunk #2 succeeded at 213 (offset -1 lines). 
Hunk #3 succeeded at 261 (offset -1 lines). 
patching file src/side.c 
Hunk #1 succeeded at 74 with fuzz 1 (offset 1 line). 
Hunk #2 succeeded at 197 (offset 1 line). 
patching file src/util.c 
Hunk #1 succeeded at 312 (offset -9 lines). 
Hunk #2 succeeded at 441 (offset -9 lines). 
touch man/diff.1

Now there is definitely something wrong with [touch man].  Surely.  This step is supposed to correct an error by making the [diff.1] file look as if it has been accessed more recently that is actually the case.  That must be sort sort of bizarre fucking bug to trip up the software based on that issue.

./configure --prefix=/usr
make $CORES_TO_USE
make install
cd ..
rm -rvf diffutils-2.8.1

Gawk is a little out of alphabetical order for some reason.  Again this was in the Toolchain.

tar -xjvf /sources/gawk-3.1.7.tar.bz2
cd gawk-3.1.7
./configure --prefix=/usr --libexecdir=/usr/lib
make $CORES_TO_USE
make $CORES_TO_USE check

This time, happily the result was:
ALL TESTS PASSED

I guess I was right about the locale thingy screwing up the test in the Toolchain build.

make install
mkdir -v /usr/share/doc/gawk-3.1.7
cp    -v doc/{awkforai.txt,*.{eps,pdf,jpg}} /usr/share/doc/gawk-3.1.7

I am going to stop commenting on these commands now - they essentially just manually install the documentation that comes with the package.  They all look a little different, but if you spot a reference to a [doc] directory, that is what it is about.

cd ..
rm -rvf gawk-3.1.7

Another refugee from the Toolchain stumbles across for the final installation, in the form of Findutils.

tar -xzvf /sources/findutils-4.4.2.tar.gz
cd findutils-4.4.2
./configure --prefix=/usr --libexecdir=/usr/lib/findutils --localstatedir=/var/lib/locate

The [localstatedir] option tells the software where to put its [locate] database file.  To be FHS compliant it needs to be in [/var/lib].  I have little concept of exactly what the database is actually used for, but at least I know where it is.
make $CORES_TO_USE
make $CORES_TO_USE check

Running /sources/findutils-4.4.2/xargs/testsuite/xargs.gnu/P3-n1-IARG.exp ... 
FAIL: P3-n1-IARG, wrong stdout output: xargs.out /sources/findutils-4.4.2/xargs/testsuite/xargs.gnu/P3-n1-IARG.xo differ: char 7, line 2 
child process exited abnormally 
[…]
# of expected passes        95 
# of unexpected failures    1 
xargs (GNU findutils) 4.4.2 
make[3]: *** [check-DEJAGNU] Error 1 
make[3]: Leaving directory `/sources/findutils-4.4.2/xargs/testsuite' 
make[2]: *** [check-am] Error 2 
make[2]: Leaving directory `/sources/findutils-4.4.2/xargs/testsuite' 
make[1]: *** [check-recursive] Error 1 
make[1]: Leaving directory `/sources/findutils-4.4.2/xargs' 
make: *** [check-recursive] Error 1 

Cock.  This error is not replicated in the LFS 6.6 log files.  Buggeration.  On a total whim, I re-ran the test with no [j2] multicore enabled.  The failure went away.  Just to test I then re-ran it with the multicore enabled again.  The failure is still gone!  Three cheers for inconsistency and a lack of logic!
make install

Again, we may need the program on boot and if /usr is not mounted it has to be in [/bin].
mv -v /usr/bin/find /bin 
sed -i 's/find:=${BINDIR}/find:=\/bin/' /usr/bin/updatedb

Accordingly to the book that [sed] command is necessary because “[t]he updatedb script also needs to be modified to correct an explicit path ”.  Explicit paths are my favourite kind.  Far better than those coy paths that leave it all up to the imagination.  Sorry, mind wandered there, tends to do that when I am faced with neuron paralyzingly confusing tosh masquerading as a command and the reason for it.
cd ..
rm -rvf findutils-4.4.2

Flex is apparently used for making other programs that see patterns in text.
tar -xjvf /sources/flex-2.5.35.tar.bz2
cd flex-2.5.35

We need to fix a bug in the software by applying a patch:
patch -Np1 -i /sources/flex-2.5.35-gcc44-1.patch
patching file skel.c

./configure --prefix=/usr
make $CORES_TO_USE
make $CORES_TO_USE check

Tests succeeded: 46 
Tests FAILED: 0
On a subsequent build I did get an error:

Results:
Tests succeeded: 45
Tests FAILED: 1
make[4]: *** [check-local] Error 1
make[4]: Leaving directory `/sources/flex-2.5.35/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/sources/flex-2.5.35/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/sources/flex-2.5.35/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/sources/flex-2.5.35'
make: *** [check] Error 2

The error was with [test-bison-nr]. As with another package, I re-ran the tests without the Multi Core option, and it worked fine.

make install

Flex is a update of a program called lex.  To ensure backwards compatibility we need to make a symbolic link for the library file:
ln -sv libfl.a /usr/lib/libl.a

We also need to make a 'lex' program.  This is not as simple as linking the flex program.  Flex itself has a compatibility mode which makes it work like the old lex program.  So what we do is write a short script called 'lex' which runs flex in the lex compatibility mode.
cat > /usr/bin/lex << "EOF" 
#!/bin/sh
# Begin /usr/bin/lex
exec /usr/bin/flex -l "$@"
# End /usr/bin/lex
EOF
chmod -v 755 /usr/bin/lex

We have not seen the cat ... EOF command for a while, but it works in exactly the same way.  The lines in that file that begin with '#' are treated as comments and have no effect.  So the only line that does anything is the [exec ...] line.

mkdir -v /usr/share/doc/flex-2.5.35
cp    -v doc/flex.pdf /usr/share/doc/flex-2.5.35 
cd ..
rm -rvf flex-2.5.35

Gettext again:

tar -xzvf /sources/gettext-0.17.tar.gz
cd gettext-0.17

The patch here fixes a permissions bug, and therefore automatically gets the thumbs up from me.
patch -Np1 -i /sources/gettext-0.17-upstream_fixes-2.patch

patching file gettext-tools/misc/autopoint.in 
patching file gettext-tools/src/write-catalog.c

./configure --prefix=/usr --docdir=/usr/share/doc/gettext-0.17 
make $CORES_TO_USE
make $CORES_TO_USE check

=================== 
All 30 tests passed 
===================

Excellent.

make install
cd ..
rm -rvf gettext-0.17

Now we have the Kid Frighteningly named Groff.  Following from the last two, this one also is involved in processing text files.

tar -xzvf /sources/groff-1.20.1.tar.gz
cd groff-1.20.1
PAGE=A4 ./configure --prefix=/usr

I've selected A4 here because I am not a burger munching gun enthusiast.  If I was I would have gone for letter.  Even if I got this wrong I could change the setting later in the /etc/papersize file.

make $CORES_TO_USE
make docdir=/usr/share/doc/groff-1.20.1 install

Again, we need some symbolic links for compatibility:

ln -sv eqn /usr/bin/geqn
ln -sv tbl /usr/bin/gtbl
cd ..
rm -rvf groff-1.20.1

The next package, for a change, is not involved in processing fucking text files.  It's an old favourite Gzip, from the Toolchain. Now, the eagle-eyed amongst you may have noticed that the book installs Grub 1.97 at this point. I am not going to. I will go into the problems in more detail elsewhere, but for now, I am going to use Grub 0.97 instead, and we will install and configure that later.

tar -xzvf /sources/gzip-1.4.tar.gz
cd gzip-1.4
./configure --prefix=/usr --bindir=/bin
make $CORES_TO_USE
make $CORES_TO_USE check

================== 
All 5 tests passed 
================== 

make install

This time we actually move some files OUT of the /bin folder and into /usr/bin, because we know we will not need them before /usr is available if on a separate partition.

mv -v /bin/{gzexe,uncompress,zcmp,zdiff,zegrep} /usr/bin
mv -v /bin/{zfgrep,zforce,zgrep,zless,zmore,znew} /usr/bin
cd ..
rm -rvf gzip-1.4

IP Route contains a bunch of network utils.  It does not contain stuff that I usually use, but is presumably necessary for other programs.

tar -xjvf /sources/iproute2-2.6.31.tar.bz2
cd iproute2-2.6.31

Part of the package would require something to do with Berkeley DB, which I presume to be a Database made at the Berkeley University.  We are not going to bother with it, and we don't care about that particular part of this package, so we stop it installing by, yes, a sed command:
sed -i '/^TARGETS/s@arpd@@g' misc/Makefile

make $CORES_TO_USE DESTDIR=

This is the make command, and it defaults to /usr so we do not need to add anything to the [DESTDIR=] option.

make $CORES_TO_USE DESTDIR= SBINDIR=/sbin MANDIR=/usr/share/man DOCDIR=/usr/share/doc/iproute2-2.6.31 install

The make ... install contains some options that we would usually see applied to the configure script.  You'll note we have not run one, so we shouldn't grumble that we have to apply them to the make ... install

cd ..
rm -rvf iproute2-2.6.31

The kbd package, a development only surprising to those astonished at the sun's continual rising, relates to the keyboard.  It has programs to do stuff like handle the LEDs and change keyboard maps.

tar -xzvf /sources/kbd-1.15.1.tar.gz
cd kbd-1.15.1

This package does not come with a configure script.  If only we have some sort of utility to create a configure script...  Oh, yes - remember autoconf:

autoreconf

The backspace/delete keys have odd behaviour unless patched, so lets patch.
patch -Np1 -i /sources/kbd-1.15.1-backspace-1.patch

patching file data/keymaps/i386/dvorak/dvorak-l.map 
patching file data/keymaps/i386/dvorak/dvorak-r.map 
patching file data/keymaps/i386/fgGIod/tr_f-latin5.map 
patching file data/keymaps/i386/qwerty/lt.l4.map 
patching file data/keymaps/i386/qwerty/lt.map 
patching file data/keymaps/i386/qwerty/no-latin1.map 
patching file data/keymaps/i386/qwerty/ru1.map 
patching file data/keymaps/i386/qwerty/ru2.map 
patching file data/keymaps/i386/qwerty/ru-cp1251.map 
patching file data/keymaps/i386/qwerty/ru-ms.map 
patching file data/keymaps/i386/qwerty/ru_win.map 
patching file data/keymaps/i386/qwerty/se-ir209.map 
patching file data/keymaps/i386/qwerty/se-lat6.map 
patching file data/keymaps/i386/qwerty/tr_q-latin5.map 
patching file data/keymaps/i386/qwerty/ua.map 
patching file data/keymaps/i386/qwerty/ua-utf.map 
patching file data/keymaps/i386/qwerty/ua-utf-ws.map 
patching file data/keymaps/i386/qwerty/ua-ws.map 
./configure --prefix=/usr --datadir=/lib/kbd

As is becoming predictable, the data directory for kbd is normally under /usr, so we need to change that in case /usr is not available at boot time.

make $CORES_TO_USE
make install

Again, because the /usr [blah blah blah blah blah] move these files:
mv -v /usr/bin/{kbd_mode,loadkeys,openvt,setfont} /bin
mkdir -v /usr/share/doc/kbd-1.15.1
cp -R -v doc/* /usr/share/doc/kbd-1.15.1
cd ..
rm -rvf kbd-1.15.1

Less is a text file viewer.  If you run a command like man bollocks_utility and the resulting text output is too big for one screen, then you would pipe the output to less, 'man bollocks_utility | less'.  Or you can just run 'less [filename]' and it will let you see the contents.
tar -xzvf /sources/less-436.tar.gz
cd less-436
./configure --prefix=/usr --sysconfdir=/etc
make $CORES_TO_USE
make install
cd ..
rm -rvf less-436

It's make's time in the final build.
tar -xjvf /sources/make-3.81.tar.bz2
cd make-3.81

This patch is described as an upstream patch, which means that the changes it makes will eventually find their way into the next version of the package.
patch -Np1 -i /sources/make-3.81-upstream_fixes-1.patch

patching file job.c 
patching file main.c 
patching file make.h
./configure --prefix=/usr
make $CORES_TO_USE
make $CORES_TO_USE check
351 Tests in 96 Categories Complete ... No Failures :-) 

make install
cd ..
rm -rvf make-3.81

We need the next package to install the manual software.  This lets you run the command 'man [name of program]' and it should bring up the manual pages for the program.
tar -xzvf /sources/man-db-2.5.6.tar.gz
cd man-db-2.5.6
./configure --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc --disable-setuid --with-browser=/usr/bin/lynx --with-vgrind=/usr/bin/vgrind --with-grap=/usr/bin/grap

According to the book the [disable-setuid] option "disables making the man program setuid to user man."  What.  The.  Fuck.  Does.  That.  Mean.  ?  Is it actually using the word 'setuid' as a verb?  Because that is the only way it makes grammatical sense.  I mean it still makes no fucking sense sense, but at least it holds together grammatically if you make that assumption.

[with-browser=/usr/bin/lynx] sets the default web browser to lynx.  This is a text only web browser that I have fond memories of using in the early 1990's.  I don't think it has kept up to date with the latest fashions in web page design though.  It is also not installed as as part of LFS, but I may have to explore installing it when I have finished LFS.  If only because the only other web browser that I will be installing is Aweb - the Amiga browser!

The vgrind and grap programs are also not installed.  They are apparently connected to the Groff program, and I cannot be bothered to work out what they actually do, as I have no intention of installing them.
make $CORES_TO_USE
make $CORES_TO_USE check
=================== 
All 11 tests passed 
===================

make install
cd ..
rm -rvf man-db-2.5.6

Modules are a little bit odd.  To the best of my guesses, what happens is that some hardware drivers are built into the Kernel itself, and some are left to be loaded or unloaded as the mood takes the users of the system.  Stuff that can be loaded or unloaded is know as a kernel module and the following package contains tools to manage them.

tar -xjvf /sources/module-init-tools-3.11.1.tar.bz2
cd module-init-tools-3.11.1

Now, strangely at this stage the book gets what I can only describe as bitchy.  And I quote:

The testsuite of this package is geared towards the needs of its Maintainer. The command make check builds a specially wrapped version of modprobe which is useless for normal operation.

Useless, I tell you.  Geared towards the needs of its Maintainer!  Really?  Want to elaborate, or did he just steal someone's signature file and not give proper attribution?  Anyway, giving a nod to the Maintainer lets run this testsuite anyway.

./configure
make check

Right enough actually, we are definitely in the realm of screeds and screeds of crap rather than simple messages and smiley faces.

./tests/runtests

The most relevant message I got was:
configure: WARNING: docbook2man not found

Hmmm.  Maybe the bitchiness was justified after all.
make clean
./configure --prefix=/ --enable-zlib-dynamic --mandir=/usr/share/man

Oh fuck a duck, we are asking for a Dynamic Zlib.  Is that not an Eastern European rapper?
make $CORES_TO_USE
make INSTALL=install install

Nice to see someone has worked out how to get stating the fucking obvious into command line operations.  When I look at that though, I cannot help but read it as INSTALL=install (on steroids).  If you are reading on in the hope that that complete bollocks is going to get a meaningful explanation, stop now.
cd ..
rm -rvf module-init-tools-3.11.1

tar -xjvf /sources/patch-2.6.1.tar.bz2
cd patch-2.6.1

One of the tests for patch requires the program 'ed', which we have not installed.  We can change this by, and the irony is not lost on me, patching.
patch -Np1 -i /sources/patch-2.6.1-test_fix-1.patch

patching file tests/crlf-handling 

./configure --prefix=/usr
make $CORES_TO_USE

Aaaaaaaaah:

/sources/patch-2.6.1/src/patch.c:1542: warning: the use of `mktemp' is dangerous, better use `mkstemp' 

Aaaaaa---oh, we have seen and ignored that before haven't we?

make $CORES_TO_USE check

25 tests (25 passed, 0 failed) 
All tests succeeded!

Good.

make install
cd ..
rm -rvf patch-2.6.1

Psmisc is like the second half of the Procps package.  It contains more utilities dealing with information about running processes.
tar -xzvf /sources/psmisc-22.10.tar.gz
cd psmisc-22.10
./configure --prefix=/usr
make $CORES_TO_USE
make install

There is some stuff in the book about a program called pidof.  This is not normally installed, and this is not normally a problem, unless we are not going to install something called sysvinit.  We are going to install sysvinit so we can ign...................zzzzzzz.............zzzz.....wat....snurfle...

cd ..
rm -rvf psmisc-22.10

The shadow program is the one that properly handles passwords.  It also has a cool name.
tar -xjvf /sources/shadow-4.1.4.2.tar.bz2
cd shadow-4.1.4.2

Coreutils has already installed a good program called 'groups', so we do not want shadow to overwrite that.  Sed comes to out rescue.  Yeah for sed!  Wait, what?

sed -i 's/groups$(EXEEXT) //' src/Makefile.in
find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \;

Also we need to disable the Korean and Chinese man pages because the man program is racist, or something true but less inflammatory.

sed -i -e 's/ ko//' -e 's/ zh_CN zh_TW//' man/Makefile.in

As this program encrypts passwords, we need to select and encyption mechanism.  The default 'crypt' is not good enough for various technical reasons, so we want to use MD5.  Was that not a robot on Star Wars?  Also we need to account for a change in the recommended location for the 'mail' directory.  Which we will not be using.

sed -i -e 's@#ENCRYPT_METHOD DES@ENCRYPT_METHOD MD5@' -e 's@/var/spool/mail@/var/mail@' etc/login.defs
./configure --sysconfdir=/etc
make $CORES_TO_USE
make install

One, by now routine, program replacement:

mv -v /usr/bin/passwd /bin

Lets also, for the sake of argument assume that we want to actually implement the password security.  We need to run:

pwconv
grpconv

When, or rather if, we add a normal user to the system, we will use the new 'useradd' program that has just been installed.  It will make a mailbox for that new user.  We will most likely not want that to happen, so:
sed -i 's/yes/no/' /etc/default/useradd

The last stage of the shadow install is to finally set our root password for the system we are building on the USB Key.

passwd root

To avoid forgetting it, I am going with 'root' as a reflection of the 'lfs' password I used earlier.  If I do get all this up and running, and security for my Amiga on a USB Key becomes an issue, I will be sure to change it.

cd ..
rm -rvf shadow-4.1.4.2

The kernel spits out messages about the operation of your system on a regular basis – and especially when something odd happens.  The following package contains software to trap these messages and store them in log files.

tar -xzvf /sources/sysklogd-1.5.tar.gz
cd sysklogd-1.5
make $CORES_TO_USE
make BINDIR=/sbin install

We also need to set up the configuration file for the software using the familiar [cat] command:

cat > /etc/syslog.conf << "EOF"
# Begin /etc/syslog.conf
auth,authpriv.* -/var/log/auth.log
*.*;auth,authpriv.none -/var/log/sys.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
*.emerg *
# End /etc/syslog.conf
EOF

The format of the file tells the programs how to deal with certain types of kernel messages.  For example, any messages detected as type [mail] are logged in the [/var/log/mail.log] file.

cd ..
rm -rvf sysklogd-1.5

The next package sounds similar, but that is only because it is adjacent in the alphabet.  The SysVInit package contains software which controls how the System boots up and shuts down.  This is not the old autoexec.bat or config.sys from the old DOS days, but instead is software which controls the boot process itself.  LFS uses a run levels system.  The idea is that there are several levels of computer 'awakeness' and certain software is configure to run at certain runlevels.  So, for instance, you would have your low level stuff like logging scripts (in the last package) on a fairly low runlevel, whereas something more glitzy like a graphical interface would be in a higher runlevel.  It works in reverse at shutdown time.  The higher runlevel software is closed down first, and then these programs descend through the runlevels until the machine is halted.
tar -xzvf /sources/sysvinit-2.86.tar.gz
cd sysvinit-2.86

We first need to make a message make more sense by changing it using … sed.

sed -i 's@Sending processes@& configured via /etc/inittab@g' src/init.c

We have also already installed the 'wall' program which is also included in this package.  We suppress its installation as follows:

sed -i -e 's/utmpdump wall/utmpdump/' -e 's/mountpoint.1 wall.1/mountpoint.1/' src/Makefile
make $CORES_TO_USE -C src

The [C] command just changes to the [src] directory before running the command.  Sounds to me like the same as running [cd src & make $CORES_TO_USE] but hey ho,
make -C src install

The configuration file for SysVInit is one of the most complicated we have seen so far:

cat > /etc/inittab << "EOF"
# Begin /etc/inittab
id:3:initdefault:
si::sysinit:/etc/rc.d/init.d/rc sysinit
l0:0:wait:/etc/rc.d/init.d/rc 0
l1:S1:wait:/etc/rc.d/init.d/rc 1
l2:2:wait:/etc/rc.d/init.d/rc 2
l3:3:wait:/etc/rc.d/init.d/rc 3
l4:4:wait:/etc/rc.d/init.d/rc 4
l5:5:wait:/etc/rc.d/init.d/rc 5
l6:6:wait:/etc/rc.d/init.d/rc 6
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
su:S016:once:/sbin/sulogin
1:2345:respawn:/sbin/agetty tty1 9600
2:2345:respawn:/sbin/agetty tty2 9600
3:2345:respawn:/sbin/agetty tty3 9600
4:2345:respawn:/sbin/agetty tty4 9600
5:2345:respawn:/sbin/agetty tty5 9600
6:2345:respawn:/sbin/agetty tty6 9600
# End /etc/inittab
EOF

OK, lets have a go at picking that apart.  Any line starting with '#' is a comment only, and is ignored.  The [id] line tells the system the default runlevel to use.  We should see this increasing when we install 'X'.  The line [si] I think just tells the system to run this package.  Then you have a list of 0-6 runlevels and the command to run at each runlevel.  The command is [rc] with an option [0-6].  What happens then is, I think, that the [rc] command runs all the scripts it finds in differently numbered folders.  These particular scripts are set up later in the installation.  Some programs which are installed will put their own scripts into these folders so they auto run on boot.  I will have to give some consideration to doing this with the Amiga software.

The [ca] line sets up what happens when you hold down CTRL, ALT and DELETE.  The next line says what happens when the root user logs in.  The last six lines of the file set up the six terminals that you can switch between using CTRL + ALT + F1-6 when the system boots.

Well, that sounded good.  Could be a complete load of shite though.  There is a man page [http://www.netadmintools.com/html/5inittab.man.html] with some more information.

cd ..
rm -rvf sysvinit-2.86

It's tar's turn to be reinstalled in final form.

tar -xjvf /sources/tar-1.22.tar.bz2
cd tar-1.22
./configure --prefix=/usr --bindir=/bin --libexecdir=/usr/sbin
make $CORES_TO_USE
make $CORES_TO_USE check
## ------------- ## 
## Test results. ## 
## ------------- ## 

69 tests were successful. 
8 tests were skipped. 
make install
cd ..
rm -rvf tar-1.22

Texinfo again.
tar -xzvf /sources/texinfo-4.13a.tar.gz
cd texinfo-4.13
./configure --prefix=/usr
make $CORES_TO_USE
make $CORES_TO_USE check

I take back the charitable comments I made about the error reports in the Toolchain build.  On reviewing the reports this time around, it is the screeds and screeds of crap type of report but with the following types of messages liberally strewn throughout the aforementioned screeds and screeds of crap:

================== 
All [x] tests passed 
================== 

Can I bothered scanning through all the screeds and screeds of crap looking for these messages to make sure everything is OK?  No Mr Texinfo maintainer, I fucking can't.  Sort this bullshit out.

make install

According to the book, we can install "the components belonging in a TeX installation", if we want to.  I have no idea whatsoever that this means.  Erring on the side of safety, lets just install it anyway.

make TEXMF=/usr/share/texmf install-tex
cd ..
rm -rvf texinfo-4.13

As we saw way back when setting up the directory structure and mounting the virtual file systems, we need some software to manage the hardware devices attached to the system.  The package for this is 'udev'.

tar -xjvf /sources/udev-151.tar.bz2
cd udev-151

Firstly, we need to some special LFS configuration files to configure udev:
tar -xvf /sources/udev-config-20100128.tar.bz2

We need to create some particular files and directories that udev cannot create for itself.  This is very similar to what we did when we were setting up for the Chroot:

install -dv /lib/{firmware,udev/devices/{pts,shm}}
mknod -m0666 /lib/udev/devices/null c 1 3
ln -sv /proc/self/fd /lib/udev/devices/fd
ln -sv /proc/self/fd/0 /lib/udev/devices/stdin
ln -sv /proc/self/fd/1 /lib/udev/devices/stdout
ln -sv /proc/self/fd/2 /lib/udev/devices/stderr
ln -sv /proc/kcore /lib/udev/devices/core
./configure --prefix=/usr --sysconfdir=/etc --sbindir=/sbin --with-rootlibdir=/lib --libexecdir=/lib/udev --docdir=/usr/share/doc/udev-151 --disable-extras --disable-introspection

The [with-rootlibdir=/lib] option sets where the library is to be installed instead of /usr because /usr may not be avail..............zzzzzzzzzzzzzzzzzzz.  The [libexecdir=/lib/udev] option sets the directory to use to install the configuration files.  The [disable-extras] and [disable-introspection] stop particular parts of udev being installed which are not necessary for LFS, and which would require other packages to be installed.
make $CORES_TO_USE
make install

The following commands install particular support for RAID [http://en.wikipedia.org/wiki/RAID], "device-mapper" (wtf?), hand held devices, and ISDN.  The latter two have a distinct 1990's whiff about them I have to say.
install -m644 -v rules/packages/64-*.rules /lib/udev/rules.d/
install -m644 -v rules/packages/40-pilot-links.rules /lib/udev/rules.d/
install -m644 -v rules/packages/40-isdn.rules /lib/udev/rules.d/

Then we need to install the special LFS config files that we unpacked earlier.

cd udev-config-20100128
make install
make install-doc
cd ../..
rm -rvf udev-151

At this point if we were following the instructions, we would install the vim text editor.  I have tried to use vim in the past, and ... fuck that shit.  I am going for 'nano' instead.  I have already managed to build that successfully, simply as an example.  Lets do it. 

So lets just 'wget' the nano...  Oh bollocks, we don't have wget installed.  Right.  Hmm.  OK, lets try this:
exit

This quits the Chroot environment, and our LiveCD image
cd /media/lfs/sources
sudo wget http://www.nano-editor.org/dist/v2.1/nano-2.1.10.tar.gz

Then we go back into the Chroot:

sudo chroot "/media/lfs" /tools/bin/env -i HOME=/root TERM="$TERM" PS1='\u:\w\$ ' PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin CORES_TO_USE=-j2 /tools/bin/bash --login +h
cd /tmp

We should now have the nano source code /sources in this folder.  What we might want to do is download this right at the beginning, which would save a hop, skip and a jump to download it at this stage.
tar -xzvf /sources/nano-2.1.10.tar.gz
cd nano-2.1.10
./configure --prefix=/usr --sysconfdir=/etc/nano --enable-color --enable-multibuffer --enable-nanorc

The [enable-color] command ... oh fuck off and work it out yourself.  [disable-multibuffer] disables multiple file buffers.  Not entirely sure what that means.  The [enable-nanorc] allows nano to be configured using .nanorc files in each users home directory.  We will setup a system wide nanorc file in the /etc/nano directory below.

In a spectacular turn of events, and completely unlike my attempts elsewhere in my blog, I id not get screeds and screeds of error messages.  Splendid.

make $CORES_TO_USE

Still no massive fuckups!

make install
install -v -m644 -D doc/nanorc.sample /etc/nano/nanorc.sample
install -v -m755 -d /usr/share/doc/nano-2.1.10
install -v -m644 doc/{,man/,texinfo/}*.html /usr/share/doc/nano-2.1.10

The helpfully named nanorc.sample file can be perused at your leisure if you are particularly interested in how text based text editors present themselves.  Let me know how that goes from you if you can tear yourself away from your album you sick philatelist.  For the rest of us, we would install a global configuration file as follows:

cat > /etc/nano/nanorc << "EOF"
set autoindent
set const
set fill 72
set historylog
set multibuffer
unset nohelp
set regexp
set smooth
set suspend
EOF

Brilliantly, BLFS recommends the option 'set nohelp'.  Hmm.  Text based text editor.  Complicated key sequences for commands.  Unintuitive interface.  'nohelp'?  hahahahahahahaha, fuck that.  That's why I have gone for 'unset nohelp' as a double negative opposite to the suggestion.

cd ..
rm -rvf nano-2.1.10

And, that, as they say, is that for the main software build.

No comments:

Post a Comment