These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.

There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.

There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.

Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.

I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The sanity check is ensuring that filesystem size is divisible by
sectors-per-track. That seems to be just an optimization for ancient
media, and quite tricky to accomplish as different dosfstools versions
produce filesystems with different sectors-per-track.

Continue processing even if filesystem size is not divisible by
sectors-per-track.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Now that nativesdk-glibc handles GCONV_PATH itself we don't need to do
this here. This unbreaks mtools for the native case without uninative
since the existing patch wasn't nativesdk specific.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Changes are mostly cosmetic, but also include one important fix
to support builds using musl libc.

  http://git.openembedded.org/openembedded-core/commit/?id=9f5eb272784d3be17e7fe8e7cab511bd4086ba1e

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

unlike glibc, uclibc does not have internal APIs implemented for
libiconv, so it needs to depend upon libiconv

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Helps building mtools on musl

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

mcopy uses the IBM850 codepage from gconv. The default install location
for gconv will not match the actual install location since it can be
pulled from sstate. This patch overrides the default location when
running by adding GCONV_PATH to the environment for mcopy.

[YOCTO #7629]

Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Fixed:
ld: cannot find -lbsd
collect2: error: ld returned 1 exit status

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

Fixed do_install error:
mkdir: cannot create directory `/path/to/image/usr': File exists
mkdir: cannot create directory `/path/to/image/usr/share': File exists

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

When build fs with mtools-3.9.9, has file /usr/bin/lz in rootfs,
it is the symlink to uz:

root@qemu3:~# /usr/bin/lz
-sh: /usr/bin/lz: No such file or directory
$root@qemu3:~# ls -l /usr/bin/lz
lrwxrwxrwx 1 root root 2 Jul 18 18:07 /usr/bin/lz -> uz
root@qemu3:~# uz
-sh: uz: command not found

But the uz isn't actually exist, so the result is that lz is a
broken symlink.

The root cause is that uz hasn't been installed when install-scripts.

Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>