apg(1) is already there but let's provide another
well known utility either, habits use to vary...

These packages have been proposed by valintinr@:
- stress is included in SRCD and was found useful;
- winusb is handy when dealing with legacy OS media.

A recent commit has dropped wireless support from
regular server images; staging modules might still
come handy in some situations, let's keep those in
but not as a part of default installation.

Yet another age old bug: `sfdisk -l' is mimicking what
a person does by hand but the script is rather interested
in what `sfdisk -g' provides, that is, geometry.

And it's stupid enough to only grok C locale.

It's all started with glebfm@ wondering why
kernel-modules-v4l-std-def ends up installed
with altlinux-p7-server-ovz.iso; this has been
tossed in by kernel-modules-staging-std-def
which has been requested by +wireless.

WiFi support is nice to have handy when one hits
a wifi-only device and no means to bring networking
up (the infamous "unzip.zip" situation) but it's
a bit too much to force a bunch of extra drivers
specifically known for sub-par or unknown quality
onto everyone installing an ALT Linux based server.

So let's contain that feature to desktop/rescue images
and exclude it from their common base with server ones.

It's been added to al of tde-based images
but it looks like LiveCDs make more sense,
and it's the regular-tde.iso that hits both
regular builds and starterkits; let's put it
there and hope it gets spotted appropriately.

This has been suggested by Oleg Ivanov:

http://lists.altlinux.org/pipermail/antique/2015-May/002353.html

...and does make sense; additions are welcome.

Ah, and fix that silly thinko with ~/.zshrc perms while at that.

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.