grub available on more platforms than syslinux.

We cannot get IMAGE_OUTPATH from the build.log, and there is currently
no other mechanism. Creating a CHECK directory was a bad idea. It should
have been created only for CHECK, but it was always created when DEBUG
was not enabled. So it's better to just issue a warning.

So much clearer and easier.
Thanks glebfm@ for the idea.

The parameter determines use of QEMU or not, if the target architecture
does not correspond to the host architecture.
By default, the parameter is on (Value 1).
For architectures that do not support QEMU (e2k), the option is turned off.

Aptbox is not initialized, so build time is reduced.

Now it cannot be set from the config ~/mkimage/profiles.mk

It was fixed in the commit:
187d0a5d

NO_SYMLINK disables the creation of symlinks for the builded image.

The BRANCH parameter indicates that the target is a starterkit and
not a regular build for Sisyphus.

Previously, you had to specify two parameters MKIMAGE_PREFIX and
GLOBAL_PREFIX with the same value - the path to mkimage. And this
behavior has not been documented. The GLOBAL_PREFIX variable is
defined in mkimage in config.mk and rules.mk.

The parameter is used to save the intermediate tarball used to
build the virtual machine image.

It was misleading already, and riscv64 is going to join the gang
(but not there yet) following aarch64, mipsel, ppc64le and more
e2k* subarches...

Use it in the image filename, so we'll know what version of a distro
it is.

Another minor facelift:
- s/ALT Linux/ALT/gc (where applicable);
- s/7.0/8.0/g;
- 2017;
- e2k;
- links.

This performs distclean upon successful image build.
Suggested-by: Andrey Cherepanov <cas@altlinux.org>

This one reduces the amount of output that's only
interesting when one is actually watching the console
during builds (at least the early stage) -- these tend
to look boilerplate and be useless when inspecting the
output of a large batch build like [[regular]] one.

This change is done to reduce ambiguity in some cases;
the previous intention has been to ease navigation when
staying in a particular directory, now it's been changed
in favour of convenient toplevel `git grep' in fact.

Both variants have their pros and cons, I just find myself
leaning to this one by now hence the commit.  Feel free to
provide constructive criticism :)

Some path-related bitrot has also been fixed while at that.

The behaviour that sort of settled didn't actually follow
the principle of the least surprise when one really wanted
to have BUILDDIR available for inspection; DEBUG=2 would be
effective to achieve that but CLEAN=0 would not.

Thanks led@ for spotting and reporting this.

Overview of the changes:
- ARM support: separate ext2 /boot, no LILO
- avoid race condition with devmapper
- trap ERR so that -e in shebang doesn't result in extra cleanup hassle
- configurable root filesystem type (ext4 by default)
- jumps through parted hoops

Details:

1. LILO is x86-specific while the rest of the script can be used
   to prepare e.g. Marvell ArmadaXP or CuBox images; we can generally
   count on uboot supporting ext2 for relatively sane platforms but
   not ext4 that would be a better root filesystem performance-wise.

2. Apparently /dev/mapper/loopXpY can be still missing at the time
   when kpartx returns and pop up a bit later... sit there, wait
   and check for it.

3. If something went wrong with any command of the script it would bail out
   due to -e in shebang; it is now better to clean up the loopback device
   and its mappings in this situation either.

4. One size doesn't fit all, really.

5. The parted sizing was sloppy as in broken, now it's just half insane.
   Someone's decision to stick units and auto-alignment knobs into
   a single one was apparently hilarious...

   http://www.gnu.org/software/parted/manual/parted.html#unit

Manual loop/dm cleanup is described in documentation just in case.

/boot size meter is suboptimal in terms of additional I/O incurred,
will be most likely rewritten to make use of advance "du -s".

These have been proofread somewhat to correspond
to the current state of affairs; a missing one
was added for fonts feature.

The original mkisofs would only care for the proper ISO9660 image
but we've switched to xorriso which is able to perform the hack
to yield UEFI hybrid images; thus no need for the postprocessing.

Requires mkimage >= 0.2.5 and xorriso (obviously).

See http://www.opennet.ru/openforum/vsluhforumID3/86239.html#1
for a query that has led to this one; in particular,
- xdm dropped (won't log in root and there are no users yet);
- network is brought up and configured via DHCP by default;
- apt-get works out-of-box;
- default image size is twice the chroot size.

Another feature suggested by Michael Radyuk (torabora):
some images are known alpha/beta quality, it's more handy
to just state this at the build time than to rename by hand.

The prerequisites for a cleanup after a successful build
were somewhat weird at this point; now the rules are:
- if DEBUG level is more than 1 or CHECK is set, don't do it;
- otherwise if at least one of the following conditions is true:
  + there's more than one target being built in a row;
  + the build was run by e.g. alterator-mkimage;
  + metaprofile directory is read only
  ...then do a distclean.

If these are still weird or feel unsuitable for profile hacking,
drop me a note (or a patch).

As it happens, adding another architecture required almost no changes;
native 32-bit ppc build took only ARCH and a repo, qemu-ppc one still
has problems (/.host/entry hangs while unpacking setup for fakedata).

Proof of concept on a QS22:

  $ make ve/bare.tar.gz
  ** ARCH: ppc
  /bin/sh: rpmvercmp: command not found
  21:41:01 cleaning up
  21:41:03 initializing BUILDDIR: build/
  21:41:03 preparing distro config
  21:41:05 starting image build (coffee time)
  21:42:48 done (1:42)
  ** image: $TMP/out/bare-20120716-ppc.tar.gz [21M]

The only thing to be fixed was setarch(8) symlinks assumption
that is correct for x86 but not for ARM.

There's also some hasher(7) setup to be done:

  mkdir -p ~/.hasher
  echo >> ~/.hasher/config <<-EOF
  def_target=arm
  #cache_dir=$HOME/tmp	# depends on RAM/storage configuration
  EOF

...and of course apt(8) should be properly set up too.

An example PoC build on a CM-A510 board (tmpfs):

  $ make BRANDING=altlinux-centaurus ve/bare.tar.gz
  ** ARCH: arm
  18:10:45 initializing BUILDDIR: build/
  18:10:45 preparing distro config: build/distcfg.mk
  18:10:46 starting image build: tail -f build/build.log
  18:14:49 done (4:02)
  ** image: $TMP/out/bare-20120706-arm.tar.gz [23M]

Minor tweaks to toplevel docs as well as some doc/*.txt,
doc/variables.txt renamed to doc/params.txt, and a brand new
doc/pkglists.txt is added (thanks manowar@ for his considerations).

Yes, mkimage-profiles is now able to build VM disk images.
So far the support is pretty basic:

- a single hard drive image with a single partition/FS
- only stock root password is configurable
- LILO is hardwired as a bootloader

The resulting images tend to boot under qemu/kvm though.

Please see doc/vm.txt for the warning regarding additional
privileges and setup required.  This was started back in
February but I still hoped to avoid sudo/privileged helper
(and libguestfs is almost as undistributable as can be)...

Thanks:

- http://blog.quinthar.com/2008/07/building-1gb-bootable-qemu-image-using.html
- Alexey Morarash who reworked that as https://github.com/tuxofil/linsygen
- led@, legion@, vitty@, aen@ for providing advice and inspiration

It wasn't exactly obvious that the actual image build
isn't started with CHECK=1.

Following m-p-d, a more involved default output directory
structure is feasible now:

  ~/out/name/date/name-date-arch.type

instead of plain

  ~/out/name-date-arch.type

This particular behaviour can be achieved by passing
SORTDIR='$(IMAGE_NAME)/$(DATE)'; note the single quotes.

Reports are also saved in this resulting structure
albeit the place is still highly debatable.

This one extracts the exact time-ordered list of script hooks
run while building the image.

Some commons refactoring is also due.

Multiple ARCHES won't just magically work without
the ability to figure out the correct apt.conf;
fortunately there's just the right example handy
in profiles.mk.sample already.

Thanks glebfm@ for feedback.

The existing implementation would handle kernel differences
just fine but a bit too automatically: if it sees xz support,
that's what will end up being used (and if there's -Xbcj binary
compression filter available for the target platform, it will
be applied unequivocally either).

It's perfectly suitabe for getting fine-tuned release images
but is also a bit too resource-consuming while developing the
image configuration which has no business with its compression.

The one and only knob is SQUASHFS (see doc/variables.txt);
to give an idea of the differences, here are some numbers
for a mostly-binary (43% as per 99-elf-stats) webkiosk livecd
and a rather less so (18%) flightgear one on a dual quad-core
X5570 node (each mksquashfs run used up all the cores):

SQUASHFS | live-webkiosk.iso | live-flightgear.iso
---------+-------------------+---------------------
fast     | 3:30 / 130M       | 5:11 / 852M
normal * | 3:37 / 100M       | 5:35 / 688M
tight    | 3:50 / 98M        | 6:47 / 683M

Thus if the knob isn't fiddled with, the defaults will allow
for a reasonably fast build of a pretty slim image; if one is
building a release or if a particular image is very sensitive
being close to the media capacity then just add SQUASHFS=tight
and see it a percent or two down on size.

Please note that lzo/gzip-compressed images are also quicker
to uncompress thus further helping with test iterations.

Thanks to led@ and glebfm@ for helpful hints and questions.

There are three more variables to adjust the redirect page:
HOMEPAGE, HOMENAME and HOMEWAIT; e.g. live-webkiosk is now
quite a bit more whitelabel.