This script hook used to lurk in live feature but was deemed needed
in cubox images too; thus it's time to move it into a standalone
feature (maybe a configurable one, even).

Thanks glebfm@ for initial shot and sem@ for discussion.

There were some changes in x86 Simply built off m-p-d
which should be propagated into ARM Simply built off m-p.

A trivial overlook fixed up.

regular-xfce managed to lack NM somehow (so it even lacked
network after being installed since some build which wasn't
identified right away unfortunately); let's fix that either
during this small refactoring.

...net uses services, not services use net.  That is,
"network" is a service that needs to be enabled by the
now-existing mechanism of "services" feature, don't be
fooled by "network services" here.

Some of those were long asking to be done but cubox project
managed to actually get them done at least to the extent
needed for it; so let's land those and prune things up a bit.

Based on m-p-d's domain-client pkglist and scripts from
installer-feature-network-shares-client-stage3 package.

Many thanks to boyarsh@ for his kind help to get this working.

NB: this works on cubox but is not yet ready for installers!

Hooray, this one is almost retired by now!

This one is also putting an end to an overly long lived hack
named vm-net by replacing it with a bit more generic mechanism.

This one supports /etc/net, NM and connman; pruning the tree
to get rid of hardwired remnants is going to take some more time.

It even works so far!

This is applicable at least to XFCE and MATE based images
(plugins for the appropriate file managers are available).

NB: basically untested with installers.

kde-i18n-uk and krusader were suggested by rom_as@ back in April;
amarok was suggested by Pulfer from Rosalab after a kind review:
http://www.opennet.ru/openforum/vsluhforumID3/90521.html#158

...as per aen@'s advice: parole can use gst0.10 specific
hardware acceleration on Cubox but Firefox doesn't, so it's
way more reasonable to download video and watch it and not some
kind of slideshow.

XFCE seems fine on that device while E17 has segfaulted on me so far
(specifically on Cubox and not on e.g. Nexus 7).

In a nutshell, cubox-xfce is an experiment into OEM-like flashware
while cubox-xfce-ru strives to become something more or less ready
for actual use.

It's different so far even if it should be more or less merged
some day so that the packagelists become reusable across x86/ARM.

This is an experimental and known incomplete support
for the system configuration that has to be done at the
first boot-up by its user since it's their choice.

This draft uses systemd which has been a requirement :-/
Thanks sem@ for helping out with the somewhat tricky
unit file for alterator-setup.

The '[alt]' signature reference in the stock package
doesn't fit current reality as the hash files for
Sisyphus/armh are *not* cryptographically signed.

This commit should be reverted when these are.

It's pretty frustrating to be able to ssh into a vm
while being unable to administer it knowing the rootpw...

That \t has lurked in the source variant of the script,
was fixed in features.in/live/live/image-scripts.d/30-users once
and still has managed to creep into this fork!

Ugh.

The issue with the original hasty code that stuck around
was that it bluntly ignored any ifdef/ifeq constructs due to
an obvious reason of being essentially a grep, not a makefile
interpreter.

It's now fixed so that e.g. arch-specific targets won't pop up
for no good reason.

Thanks ldv@ for discussion and a reminder about the dump mode
(make -p).

lib/*.mk aren't going to be parsed for build targets
in the near future; and the early placement of those
targets was superseded by a dedicated configuration
snippet directory so just move these bits there.

Let's only build it on i586 until gnustep packages are fixed.

...and on other direct non-build actions like clean or help.
How could this stay overlooked for so long?

- 1.1.x branch: public alpha development status
  + new subprofile: rootfs
  + new features: armh*, deflogin, init, services
  + refactored features: build-*, efi, fonts, live, x11*
  + tar2vm got rewritten as tar2fs, gained ARM support
- minor spec metadata update

I've finally moved away from LC_MESSAGES=C on my main
development system half a year ago and finally spotted
that a grep for "Stop\.$" stopped to yield anything now.

It's neither reasonable nor installable on ARM,
so far dropping it is better than any workarounds.

Those based on x86 ones but pruned according to armh repo
presence; most notably, these are missing:

compiz compiz-gtk
java-1.6.0-sun mozilla-plugin-java-1.6.0-sun
libreoffice
remmina
xfcalendar
yagf

These are intended to run on Cubox ARM systems.
Tough childhood, plastic toys...

This one cares for SolidRun Cubox support.

This one cares for the less platform-specific aspects
of Marvell Dove platform support.

It was actually done much earlier during an experiment with
Marvell ArmadaXP but is now integrated more or less properly.

NB: ext2 is not needed anymore (uboot should do it),
ext4 should become configurable by an existing knob.

It was implemented in a pretty quick-and-dirty way
for regular-mate back then, clean things up a bit.
Package lists should be deduplicated either but
that's another story.

gdm-theme-simply is still around but turns out that it counts
on gdm2.20 (providing gdm) to be installed, and it is not;
thus gdm-3 is actually pulled in and it doesn't work here.

The package should be dropped from Sisyphus probably,
let's drop it here anyways.

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

This is ARM-specific (more specifically, Marvell ArmadaXP-specific
for me right now) but doesn't hurt if the module is absent.

The generated comment went wrong when the script was renamed.

The issue at hand is the hack to be employed in the init feature:

	@$(call add,THE_LISTS,$$(INIT_TYPE))

where INIT_TYPE is set separately; $(value $V) would leave that kind
of substitution unmolested while we would actually need it done.

A service a day makes the boot a long wait!