The creeping wireless bits should be thrown together,
including kernel modules, firmware, CLI/GUI controls,
and any plumbing required.

So far it's what should be tested, after all...
and #27941 is not so clearly about the kernel.

This should really be done in e17-default but until it's there...
(thanks aris@ for advice)

The things like fdisk are very useful on a livecd/liveflash
to carry in one's pocket indeed.

Just drop it from this pkglist.

Thanks someone for feedback:
http://www.opennet.ru/openforum/vsluhforumID3/88025.html#285

UEFI support is pretty requisite by now;
and el-smp hasn't seen updates for almost
half a year by now so an actively maintained
one is clearly preferred.

- regular images

See http://www.altlinux.org/Регулярные_сборки_образов
for the idea behind this set of images; in short, it's
*not* a bunch of polished end-user distros in a moment
but rather to facilitate Sisyphus package base testing
in as-is state during branch pre-release time.

It shouldn't overwrite the pre-existing configuration
but should fire if there's none.

Was long overdue already but let's leave that in 2012. :)

This one provides apt configuration for the LiveCD itself
as well as extra hooks for a livecd-install made system.

Installable live systems can have LUKS as well
and it's welcome addition to rescue images too.

This time it's

  xorriso : FAILURE : -volid: Text too long (33 > 32)

and todo-- as well.

It's a separate installation step to set the LUKS password;
see also #28200 for (terse) discussion and instructions on
getting this actually working for a distro.

For MATE regular images right now
but should be more widely useful.

Thanks gns@ for his help in figuring these out;
some metapackage related optimization is still due.

These are out there in Sisyphus and should be used
instead of copious lines in a package list.

Thanks sem@ for proposing gnome-icon-theme to supplement
the lack of icons in the default theme; note that tango
set doesn't quite cut it, even with extras.

Thunar -> thunar; xfcalendar -> orage

Borrowed from m-p-d's init-xdg-user-dirs, of course.

Slowly fixing up the discrepancies...

There's use/x11/kde already but that serves somewhat different
purpose as of today; the naming issue (kde vs kde4) was tersely
discussed with sin@ at the time of the merge of his KDE4 image
related bits and it's still not that clear.

Let's try this way and see if existing images would be ported
to use/x11/kde4.

This marks 0.17.0 hitting Sisyphus to much delight.

A few things have changed...

The whole live-rescue needs a massive facelift regarding
applications included and user experience achieved (remember
that folks are going to be stressed enough already with data
lost or system(s) not booting, and probably offline as well);
but at least it's UEFI bootable now.

The rescue feature intentionally doesn't pick up THE_PACKAGES
and THE_LISTS into stage2, so add EFI ones explicitly.

It was long overdue since (U)EFI support for live images
has been there for some six weeks or so already.

The (funny but somewhat confusing) problem manifests itself as

  E: Couldn't find package Binary

during a build run in the profile where a tagged packagelist
referenced by a specific target being built is open with vim
(which results in .FILE.sw? temporary file lying aside).

The script hook naming advice and "+name" puropose explanation
seem to have been missing.

There's a possibility to run into IA32 EFI but that's rather
uninteresting hardware (ancient Xeon servers and <s>outdated</s>
early Intel Mac laptops).  Just drop it on the floor.

As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image
which boots with all combinations of BIOS/UEFI by CD|DVD/Flash
(or at least should boot), some downgrace seems due: use/efi will
turn use/isohybrid on non-x86_64 -- which will require further
tweaks on PPC/ARM some day.

- enhanced uefi support

That FIXME has been FIXED already.

I will test more in kvm
I will test more in kvm
I will test more in kvm
...

Intermediate one: build-propagator *is* run off stage1,
no mkimage changes for that matter so far.  This means
that m-p still duplicates mki-pack-boot to some extent
but the way to dedup this is still not clear enough...

The initial approach required some quite involved postprocessing
as described in http://www.altlinux.org/UEFI#HOWTO; after having
ironed out the kinks so that initial EFI support could be merged
into mkimage proper we're better off just using it, eh?

A next part in systemd conspiracy practice: this time it tried
to take over the installer but was caught on site!