It pulls in a huge pile of dependencies including
libopenblas -- this should be fixed in repositories
of course but let's do something on our end too...

It's still recommended unfortunately.

These make no sense as kdebluetooth is officially broken
in TDE 3.5.13 and hal is used for power management.

It's been both somewhat problematic as of plymouth-0.9.x
due to broken rendering and explicitly asked for by asy@
regarding sysv-tde starterkit which makes sense for an
image targeting low-resource systems as well.

It's been asked for by asy@ and added to available packages,
not to base installation.

It's been noted by aris@ that the experimental
regular-leechcraft.iso lacks both upower and bluez;
let's try and add those missing to all of regular
desktop images.

LiveCD would hang with "Initializing Azoth: first stage"
during startup otherwise; see ~/.leechcraft/warning.log

This is our answer to this VZstats FAQ entry:

  Q: Why is it opt-out rather than opt-in?
  A: We just don't have a good place
     (such as installer or some GUI)
     to ask you for opt-in.

Well ALT Linux got one. :)

This one adds vzstats(8) reporting utility,
see also http://openvz.org/vzstats; it's only
relevant for hosts running OpenVZ, obviously.

A minimalistic paint application, just in case.

The new archdep part has been initially included into
"The Basics" chapter which it doesn't really belong to,
let's move it into Addendum.

NB: I'd better try building a package and skimming over
    at least the index upon having modified docs next time.

- archdep pkglists

Build process would choke on "unescaped" stuff otherwise,
and these blocks should be blockquotes in the first place.

This is known to work using 5.2.2/5.3.0 packages
but is still pretty basic regarding functionality.

This one relies on kde5-*/kf5-* packages still in heavy
development but the results are starting to work now.

An initial draft.

This is a single-package DE by now, might change
towards the whole bunch of modules (but then again
might not); see http://leechcraft.org for details.

hwinfo has evaded the lists so far [fixed];
inxi has just been packaged by cas@ [thanks].

This is an initial implementation of architecture dependent
contents handling for package lists more or less in the vein
of mkimage-profiles-desktop's one *but* using suffix part to
filter words in or out *not* prefix part to replace it with
a comment marker (thus filtering out lines).

The syntax should be pretty obvious:

  a b@i586 c@x86_64

will get "a b" given ARCH=i586 and "a c" given ARCH=x86_64;
please see doc/archdep.txt for a more elaborate description
and a conversion script.

- modularized stage1 modules list

It's been found out that live_rw isn't going to work
without ext4 module being available; let's ensure that.

This one has been brewing since last autumn but the need
to cut down the stage1 (propagator) modules has been stopping
the code from showing up in master branch; now that the proper
infrastructure is in place it's there too.

This target is responsible for providing isolation
of local hard drives and networking from the system
running off the LiveCD/Flash.

This one is likely to get just a single user right now
but the future potential is clearly higher.

Please do review libzmalloc implementation if concerned.

This is sort of laying the ground for the future dismantling
of 10-stage2 (which was sub.in/stage1/modules just recently);
things look like tagged lists might become due some day, e.g.
"net+usb" or "scsi+raid" -- time will tell.

These are aimed to test the modules.d/ and auto-pickup
implementation as well as to present an example.

At least 50-net might change (or just get renamed to avoid
auto-pickup) some day as the "net" feature's meaning is
to provide networking upon bootup and these modules are
only needed within stage1 if we're going to netboot;
and that's quite different thing.

armh-cubox bits are prone to get renamed/generalized too
since e.g. ArmadaXP based server images are going to need
this as well.

These were produced off the single sub.in/stage1/modules
file using this scriptlet to prefix/annotate the names:

  grep '\.ko$' modules \
  | grep -v / \
  | while read m; do \
  	echo "$(find /lib/modules/$(uname -r)/kernel/{drivers,fs} \
		-name "$m" -printf %P $m $(modinfo -d "${m%.ko}" 2>&1)"; \
    done

...with subsequent sorting and manual separation.

This is meant to be the second stage in monolithic modules
file split, so the lists themselves are largely unmolested
otherwise.  The plan is to further split those into prefix-
and module-specific ones.

Add a note clarifying 10-stage2's status, by the way.

What was a static sub.in/stage1/modules (and the only one)
is now features.in/stage2/stage1/modules.d/10-stage2
(basically a compatibility file that might go some day).

It will be auto-picked as its name corresponds to the
NN-SUFFIX pattern specified in stage1 subprofile now
with $(FEATURES) going into default STAGE1_MODLISTS.

stage1's got prepare-modules target collecting
modules file snippets all over stage1/modules.d/
subdirectories within individual features.

stage2 now adds names of all the features going into
a particular image as snippet file suffix list so that
individual features don't have to register themselves
twice (as a feature and as a propagator modules.d
snippet carrier).

This is going to allow both "uncommon" modules getting
included with no problem (sin@ has wanted cifs ones
for quite some time, for example, and some want e.g.
infiniband modules) *and* to reduce the actual list
below the common mark as well (which is the case with
live-privacy image, for one).

And stage1 memory consumption does matter in some cases
as it's highly critical with no chance to use swap yet.

...and split off use/live/.base *without* use/deflogin/live.

There's need for live images without predefined logins
(like e.g. live-privacy image).

NB: this commit might break things for someone, please notify.

The unfortunate thing is that we have to take care
for sessions, somehow; still there are only two for now
(LXQt and KDE5 Plasma Desktop) so this doesn't look like
a disaster just yet.

Thanks zerg@ for having packaged it finally.

Yet another "how did we miss this?" package
containing ubifs utilities, among the rest.

It was found out during the "from scratch" walkthrough
over http://altlinux.org/m-p with a new user that the
proposed test build run isn't clear regarding the proper
current working directory (wiki refers to QUICKSTART
copy over at http://git.altlinux.org, and this file has
been written with assumption that it's being read from
within the repository's toplevel directory; the resulting
context isn't consistent in that regard).

e.g., `make distro/icewm' instead of `make distro/icewm.iso'
would be "successful" as there's a corresponding target indeed
but the "success" would just mean building the configuration
without running the actual build.

Thanks cas@ for hitting this issue and reporting it.

PS: note that the initial flagless implementation turned out
    to produce false positives for e.g. `make distclean'.

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.

The __frontend variable was introduced to address the needs
of alterator-mkimage module: list the images available in
one column, purge the builddir.

Looks like we should consider other cases with redirected
stdout (cron builds, piped calls, etc) like fundamentally
non-interactive and behave the same.

So commit 3a8af6b5's
description is wrong now; the current cleanup rules are:

- if CLEAN=0 or DEBUG>1, don't do it;
- if CHECK or REPORT 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;
  + stdout was redirected (cronjob, alterator-mkimage...);
  + metaprofile directory is read-only
  ...then do a distclean.

If that doesn't suit your needs, describe the particular
situation please.

Thanks cas@ for wondering aloud whether greppable output
is unsupported with `make help'.

sem@ noted that it had to be dropped from xfce4-full metapackage
as this package is built on top of gstreamer 0.10 and the API it
uses was dropped from gstreamer 1.0 so it's gonna die some day;
upstream recommends xfce4-pulseaudio-plugin but it's not suitable
to some of us, like Speccyfighter; well let's add the good ol'
plugin to sysv based flavour for now and see how it holds.