Assuming that you followed the previous chapter and created a 64-bit server and workstation build-space you will have already created the common copy of the portage tree. If you have not already created this shared copy you can rsync the portage tree from a portage mirror to the live portage directory as shown below.
When we installed the 64-bit build-spaces in the previous chapter we already had a convenient stage 3 archive which we had downloaded and used to install the build-server. As we are now configuring a 32-bit build-space the first task is to download a suitable stage 3 release and unpack it into the build-space, unless this is not the first 32bit build-space you have configured in which case you will obviously already have the archive.
Next we need to create some mount-points so that we can mount the common portage related files, the destination volume for the packages that this build space will produce as well as critical common configuration files and system directories from the main build server which will be bind mounted into the build space to ensure that configurations and capabilities always remain synchronised.
We can now add entries to the /etc/fstab file on the build-server to automatically bind mount the shared configuration objects and the portage related directories into the build-space. As you can see from the example below some directories are mounted using the rbind directive to enable recursive binding so that sub-mounts are also bound correctly.
#<source> <destination> <none/bind>
/dev /mnt/buildspaces/x86-32bit-server/dev none rbind
/proc /mnt/buildspaces/x86-32bit-server/proc none rbind
/sys /mnt/buildspaces/x86-32bit-server/sys none rbind
/etc/resolv.conf /mnt/buildspaces/x86-32bit-server/etc/resolv.conf none bind,ro
/mnt/repositories/distfiles /mnt/buildspaces/x86-32bit-server/mnt/portage/distfiles none bind
/mnt/repositories/testing/x86-32bit-server/portage /mnt/buildspaces/x86-32bit-server/mnt/portage/portage none bind,ro
/mnt/repositories/testing/x86-32bit-server/overlays /mnt/buildspaces/x86-32bit-server/mnt/portage/overlays none bind,ro
/mnt/repositories/testing/x86-32bit-server/packages /mnt/buildspaces/x86-32bit-server/mnt/portage/packages none bind
/mnt/repositories/testing/x86-32bit-server/kernels /mnt/buildspaces/x86-32bit-server/usr/src none bind
/var/tmp/portage /mnt/buildspaces/x86-32bit-server/var/tmp/portage none bind
With the corresponding entries in place in the /etc/fstab file we can mount the bind-mounts we have configured manually so that they are in place as they would be had the build-server just booted.
So that we can more easily determine whether we are working with the build-server or one of its build-spaces when entering commands we shall add a prefix to the bash prompt of the build-space as shown below.
# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs
PS1="32bit-SRV ${PS1}"
This prefix will ensure that we always know which build-space we are working on when we enter it using the chroot application as shown in the example below.
Now that we are in the build-space we can update the environment and source the current profile so that we are using the correct environment settings from the build-space and not those inherited from the build-server.
We can now set the build properties which will be used by this build-space when creating binary packages. You can see in the example below we have used a very minimal set of configuration options at this stage. The first block configures the compiler flags which will be used and should be modified to reflect the architecture in use. The second block configures the location of portage related files. The next entry enables various features which are required for our configuration such as building binary packages. Finally we set some miscellaneous build options and the linguas we wish to use.
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe -mno-tls-direct-seg-refs"
CXXFLAGS="-O2 -march=i686 -pipe -mno-tls-direct-seg-refs"
PORTDIR=/mnt/portage/portage
DISTDIR=/mnt/portage/distfiles
PKGDIR=/mnt/portage/packages
FEATURES="buildpkg sandbox collision-protect -preserve-libs"
PORTAGE_NICENESS=0
MAKEOPTS="-j4"
LINGUAS="en en_GB"
We also need to edit /etc/locale.gen to only generate the locale files which will be used on this installation. Here we have enabled ISO-8859-1 and UTF-8 locales for English as spoken in Great Britain.
en_GB ISO-8859-1
en_GB.UTF-8 UTF-8
Configuration of the build-space can be completed by selecting the correct system profile by using the eselect application as shown below. As this is a build-space for a server configuration we have selected profile 1 which is fairly minimal and thus suitable as the basis of a server configuration. If we were configuring a build-space for a workstation configuration profile 2, 3 or 4 would probably be a better choice as more of the recommended desktop use flags would be enabled by default.
[1] default/linux/x86/10.0 *
[2] default/linux/x86/10.0/desktop
[3] default/linux/x86/10.0/desktop/gnome
[4] default/linux/x86/10.0/desktop/kde
[5] default/linux/x86/10.0/developer
[6] default/linux/x86/10.0/server
[7] hardened/linux/x86/10.0
[8] selinux/2007.0/x86
[9] selinux/2007.0/x86/hardened
[10] selinux/v2refpolicy/x86
[11] selinux/v2refpolicy/x86/desktop
[12] selinux/v2refpolicy/x86/developer
[13] selinux/v2refpolicy/x86/hardened
[14] selinux/v2refpolicy/x86/server32bit-SRV portage / # eselect profile set 1
With the build-space configuration complete we can ensure that the build-space is up to date. The commands shown in the example below will ensure that the system is using the latest packages, that python and perl modules have been correctly updated, that any packages which are no longer required as dependencies have been removed and that dynamic linking consistency has been tested and, if necessary, packages have been reinstalled as required.
We can now build binary packages for everything in use by this build-space by issuing the commands below. The first will perform a pretend merge so that you can see which packages will be built.
We can also install a set of kernel sources which will be used by the clients of this build-space and any applications we install in the build-space which require access to kernel sources to build.
Once the binary packages for this build-space have been built we can exit the build-space as shown below.
You can now return to the beginning of this section and repeat the process for the workstation configuration and any other configurations which require their own build-space.