It was missing indeed; thanks cas@.

Thanks cow@ for his work on Cinnamon and for being helpful;
see also http://altlinux.org/regular regarding the whole affair.

Thanks cas@ for suggesting to get rid of the former
for being superfluous and ugly as well as to add
the latter which has been missing.

It's a must to look up battery charge, after all.

These were becoming a bit longish already.

As a matter of practical distribution use
these two appeared to be rather missing.

Folks have been wondering already whether e.g. t6 breakage
qualifies as a bug; it does indeed unless the "broken" part
depends on the features not available with that branch yet,
e.g. EFI support.

It wasn't spotted when introducing the distinct kernel feature;
will need fixup as we meet packaged ARM/PPC kernels.

Somewhat silly but still: fglrx got fixed up for 1.12 by now
*but* 1.13 broke it as usual.  The updated warning thus holds.

un-def was a desperate measure when std-def of the day
was suddenly plain broken.

This reverts 0e8871e7.

No longer needed as every regular-* x86_64 image
would do UEFI by now.

Its support was dropped in mkimage some time ago
since xorriso semantics changed quite considerably
and the tweak that was done here is now performed
out-of-box thus no longer needed.

The nice and pleasant effect of hitting this barrier
is build process break at (almost) the very end of it.

Was an oversight to miss it.

connman is now required by econnman,
and aris@ has packaged e17-module-*.

- homeros-nano image is renamed to homeros-mini;
- homeros/homeros package list is added;
- default volume changed from 100% to 75.

- homeros

Thanks lakostis@ for the suggestion; e.g. some Intel Mac systems
won't provide temperature sensors until microcode is updated.

0.2.6 has fixes for xorriso and support for refind.

Unfortunately, current lightdm is broken regarding autologin at least
(1.1 or 1.0 used to work just fine IIRC).

Thanks zerg@ for nice metapackage :)
Hope others will follow the suit.

As suggested by aen@.

...since it's used as a default mail handler, which seems reasonable
for this particular case. (thanks aen@ for reminding)

It's a next-get CLI for wireless interfaces, see also
http://linuxwireless.org/en/users/Documentation/iw

See also http://wireless.kernel.org/en/developers/Regulatory/#CRDA

It's aimed at providing UEFI shell implementation which is very
useful for repairs and debug; if the "signed" mode is requested
then the signed variant is used either.

Please note that there are two distinct uses:
- a shell lying around on a filesystem to be copied by hand;
- a shell available in EFI part of boot media to be launched
  by firmware's or standalone boot manager (e.g. refind).

That enables additional packages and setup to deal with Restricted Boot.

UEFI shell is pretty valuable debugging and fixup tool.

When one has to mess with Restricted Boot, openssl and
some PE signing tools might come handy either; see also
http://www.rodsbooks.com/efi-bootloaders/secureboot.html

Its bootloader autodetection capabilities can prove quite useful;
this particular addition has been "sponsored" by this thread:
http://lists.altlinux.org/pipermail/sisyphus/2013-January/subject.html#359481

PCManFM users seem to benefit from those being available;
thanks aen@ for the exact package list.

Might come with e17 distros; the services should really become
configurable, msp@ and sem@ need that already.

Thanks manowar@ for both fitting NM there and subsequently
wrestling EConnMan into its place, things seem better now.

Let's provide the official terminal emulator as the reference one,
and those preferring others are welcome to include these either.
(to some extent this commit is biased towards regular.mk though)

Both look like useful additions.

It was missing THE_GROUPS rather completely (but should not care for
LIVE_GROUPS -- are these useful anyways?); thanks sem@ for spotting.

Suggested by zerg@, aen@ and myself upon testing.
Happens to work these days, hooray!

The reason is that the most interesting live images by now are
installable ones, and while configurable boot order is not there yet
the "classic" livecd images will require manual choice to boot.

Thanks sem@ for reminding of that FR (which is still open).

Thanks aen@ for suggesting this.