- 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.

- support USB3, ACPI suspend

This one has been requested by a user over at #altlinux
and seems working, at least when built on p7/branch.

This one is a minimalistic one to test propagator
without having to add the debug stanza by hand
as well as to run stage1 build/test cycles faster
(would have helped me understand the recent thinko
with xhci-hcd vs xhci_hcd, for example).

...just like any other stage2 based boot target,
both for consistency and specifically for propagator
test image.

Yes these bits are related to distro/ prefixed images
still the overgeneralization in distro.mk didn't pay off
but rather hid a bug with the only boot/isolinux in use
having no dependency on use/syslinux (which is required).

Maybe this will get revisited when we have other kinds
of bootable images with other bootloaders (vm/ ones care
for themselves as of today).

Commit 657c0bf6 has silently added use/bootloader
to the base use/install2 target thus breaking
experimental distro/netinst; it seems better to
require *a* bootloader in the target that's been
specifically designed to cover the common case
(thus linked to by +installer shortcut) but still
to have our base lightweight and flexible.

This doesn't hurt the actual distros as these use
+installer of course.

Looks like it's been dumped in along with the rest but not
actually used in {make-initrd-,}propagator; the problem with it
is that snd-dummy.ko matches and pulls a bunch of unrelated
modules where these don't belong (grep -w wouldn't match
snd_dummy.ko though).

These can be found in (semi-)supported branches still:

- loop.ko:
  + 3.0.101-std-def-alt0.M60P.1
  + 3.4.96-led-ws-alt0.M70P.1
- aufs.ko:
  + 2.6.32-el-smp-alt31
  + 3.4.96-led-ws-alt0.M70P.1

ehci_marvell.ko isn't found in contemporary sisyphus/armh
kernels but let's purge it later during archdep rewrite.

NB: libusual.ko has been renamed to usb-libusual.ko as of p6
    (not to be found in p7 anymore), and nls_base.ko was in
    2.6.32 kernels as of p6 but not there in p7; purge these
    somewhere down the road.

This file has been floating around for quite some time,
and some of its contents are pure bit rot by now...

Drop the modules that don't exist as of 3.19.2-un-def-alt1
upon manual diff examination.

It wasn't sdhci_pci.ko back in 2.6.32 actually and it's
sdhci-pci.ko; so grep used by mkmodpack won't pick it up.