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!

live-{gnome,cinnamon,mate,sugar} have been superseded by regular-*
(see regular.mk); live-mate-systemd has no sense now either.

It has value of its own and can be used standalone;
autologin does require autostart though.

Adjust x11 feature targets accordingly.

Hardly belonged there in the first place and became a culprit
during armh branch development since it had to be forked in
an ugly manner; move to rootfs hooks and be done with it.

VM images will be able to benefit either *but* installed systems
might have some trouble when this is implemented:
http://lists.altlinux.org/pipermail/devel/2013-May/197447.html

Split off use/live/x11 as a common free/proprietary ground either
(this refactoring had to be performed in parallel with x11 feature
being revamped, diffs quickly became intertangled unfortunately).

This has had several goals:
- a target suitable for x86 and armh providing a rather
  minimal set of base xorg packages and generic drivers;
- task-oriented targets for graphics use cases:
  + "desktop" means rather 2D focus with 3D being welcome
    or even essential but not performance critical, thus
    "a slower driver is fine as long as it does work";
  + "3d" means specific 3D performance being critical,
    that is "no 3D means no use at all".

Regarding the free and proprietary 3D-capable drivers:
the previous idea was to split out some common ground
and then add the contenders on top of that; the current
approach is based on the observation that the live images
requiring proprietary NVIDIA/AMD drivers *by default*
are usually of not much use with hardware that lacks
proper 3D acceleration (like Tseng cards) or the driver
support for that (like Matrox these days).

Intel videodriver makes for a special case though:
it is both free and top-notch performer.

Thanks sem@ and boyarsh@ for discussion.

PS: xorg-drv-{keyboard,mouse,void} dropped;
those who need these can usually help themselves.

These handle only VE-like products (think TWRP on Nexus 7);
the proper image support should be backported later on.

An experiment in layered configurations is still in its
early stages regarding ARM zoo...

The feature officially introduces the "engineering passwords"
including empty ones which have been around since forever but
weren't properly managed (and still are not, at least until
there are no stray passwd/chpasswd/usermod calls in both the
profile, installer-features and all the other related parts).

It is based on an m-p-d init3-users script by stanv@ but was
cleaned up and restructured in a pretty severe manner; thanks
glebfm@ for additional discussion.

This also cleans up the kludge previously stuck into build-vm.

Note that vm/icewm sports graphical autologin now as well as
the default root password (which can be overridden by passing
ROOTPW=... to make but it is a change from the previous state
of affairs indeed).

This one is finally there and should help reduce the
systemd-induced mess in package lists and specifications.

The issue is that use/fonts/infinality doesn't actually
require the script hook thus registering the feature's
name in FEATURES variable so that the feature's contents
get copied over is not neccessary (distcfg.mk build-up
will have happened anyways).

But that's confusing if one's forgot this peculiarity
(like me today) or never knew of it, so let's spare
some frustration.

This feature is more generally applicable indeed;
might result in duplication due to the installer
components adding "efivars" independently but that
is to be sorted out later in those components:
- check whether it's added already sometime soon;
- maybe stop adding that at some point in the future.

install2 and rescue roots still need this too though.

This feature should be more generally applicable indeed.