- going nightly

The issue has shown up in regular-*-20130207: /etc/resolv.conf
would suddenly be empty upon successful bootup in virtualbox
with a single DHCP configurable ethernet.

dmesg has some trouble signs:

  aufs au_lkup_neg:267:kworker/0:2[998]:
  I/O Error, resolv.conf should be negative on b0

sem@ tells something like that has been seen before in a different
configuration (multiple aufs overlays with /etc/ and /var sitting
in different ones resulting in broken hardlinks); rescue boot with
a test "echo > /etc/resolv.conf" yields an I/O error either.

The patch is loosely based upon livecd-net-eth and
m-p-d::profiles/live/image-scripts.d/init3-{network,resolve}.

See also #28484 for the (still ongoing) discussion.

enp0s3 is quite inferior to eth0 in terms of usability
even if it might be more convenient for the machine{,ry}.

Let's stick with what works here in ALT Linux (see #28484).

Once upon a time the first and only ethernet interface
on a Linux system used to be known under the name of eth0;
but years passed and the systemd shadow has drawn closer
even to the seemingly remote areas like interface names.

In short, it might get named e.g. enp0s3 (a more human
friendly name of course) and the exact name is to be
figured out in runtime as well.

Sigh.

See #28390, #28473 and #28471; thanks zerg@ for reminder.

The issue is that gfxboot's gettext support works on "label"
strings but doesn't work properly on "menu label" ones as of 4.04
(the "menu label" translations pop up in the "Loading ..." window
but menu items themselves are unaffected thus untranslated).

NB: debian wheezy's syslinux-4.05 package patchset contains
somewhat related 07-gfxboot-menu-label.patch; might be worth
attention given that debian folks participate in upstream.

Pretty natural but delayed somehow...

It's specified in http://altlinux.org/regular and it rather modest
(~13M image size growth on i586).

See also http://altlinux.org/domain for description;
this should allow for client support.

Now this is ugly: instead of commoditizing the repetitive code
the result ended up working differently by creating several
repositories for the target subdirs instead of the single one
for the generated subprofile as a whole.

This results in .disk/profile.tgz being basically useless
in every image since c4311108.

These generated directories aren't part of a profile itself.

The same "regular-gtk" based set of images received common
desktop background provided; note that kde4 won't like it
(branding package didn't really anticipate kde4 and is to
be updated appropriately as well as extended for mate/fvwm).

This one is also used for lightdm/gtk.

"regular-gtk" based images moved from the (unsupported) gdm2.20
to the (supported) lightdm with gtk greeter; while a couple of
gdm2 forks have emerged it's still unclear whether mate or mint
one will be actually alive, even short/mid-term.

Helps with #28470 (FAT not being recognized) which is critical
due to ESP being FAT by spec :-/

Thanks timonbl4@ for the hint.

The issue is that it's suddenly broken in current Sisyphus,
looks like the peculiar set of assumptions in fedora-tweaked
systemd+plymouth+gdm3 relies on tty1 being the X session tty
and it's different here.

- assorted fixes

It appears that manually specified IMAGEDIR, e.g. by adding

  IMAGEDIR = ~/out/$(shell date +%Y%m%d)

to ~/.mkimage/profiles.mk, might be problematic due to
missing globbing.  Let's make sure the paths are globbed
and directories are created -- since make's wildcard()
returns an empty string when there's nothing there [yet].

It's a bit superfluous so far; this isn't a final decision
but rather a current change of mind though.

This is largely a workaround for #28239.

The metapackage is out there but mate-media-apps seems
like not available at the moment.

Some file managers (particularly Dolphin) depend
on avahi for network service browsing; turn it on
if it's there.

This might have been related to the plymouth bar missing
at live system shutdown.

It appeared that plymouthd.conf wasn't set up properly
thus "service plymouth stop" didn't result in anything
meaningful; thanks boyarsh@ for his help figuring this
out again.

Looks like LUKS has had its share of testing,
now it's plymouth's time again.

Thanks boyarsh@ for m-p-d implementation and sem@ for the hint.

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.